Email Security, Without the Guesswork

Start with the action an email asks you to take

A recognizable name or a polished design does not settle whether a request is legitimate. Before you sign in, disclose information, install something, or change a payment process, ask whether the request was expected and how you can verify it independently. Our phishing awareness guide explains that decision in practical scenarios.

Use the service’s normal app, a known bookmark, or an established contact route. Do not rely on a phone number or alternate address supplied only by the questionable message. For workplace mail, use your organization’s verification and reporting process.

Authentication is useful context—not a safety certificate

SPF, DKIM, and DMARC address particular questions about sending domains and message authentication. They do not certify every statement inside a message or guarantee that a request is trustworthy. Our plain-language authentication guide separates these roles and offers planning questions for domain owners.

Technical reference: Google’s sender guidance in our sources library. The guide explains the provider’s scope; do not assume one provider’s requirements apply unchanged everywhere.

Review the account around the inbox

Know how you sign in, how you would recover access, and which devices or applications have permission to use the account. Make changes through the provider’s legitimate settings. Keep recovery codes and other secrets out of casual notes or shared documents.

Our account security checklist turns this into a review routine, with the provider reference linked in the article. The checklist is not an account audit and does not produce a verified security grade.

Reporting and recovery are different from ordinary cleanup

A suspicious request is not just another newsletter to organize. Use your provider’s phishing-reporting tools or your organization’s approved channel. If you already entered credentials, approved an unexpected sign-in, or ran an unfamiliar file, use the legitimate recovery or support process promptly and describe what actually happened.

Do not assume deleting the email reverses an earlier action. Equally, do not claim compromise from an unclear observation alone. The appropriate response depends on the event and the relevant support guidance.

Build one repeatable verification rule

Try this suggested rule: verify unexpected, consequential requests through a route that does not depend on the message itself. Keep the rule available when a request is urgent or convincing. Then connect it to a clear reporting route and a periodic account review.

For provider-specific guidance, visit our phishing reference and account security reference. For the surrounding workflow, continue to Email Management.