Email Authentication Protocols

SPF identifies authorized sending servers for a domain. DKIM adds a cryptographic signature to prove the email was not altered in transit. DMARC ties them together by verifying domain alignment and instructing the receiving server on what to do if an email fails both checks.

To implement these in Microsoft 365, publish an SPF TXT record including spf.protection.outlook.com. Then, enable DKIM in the Microsoft Defender portal and publish the generated CNAME records to DNS. Finally, publish a DMARC TXT record in your DNS provider.

For Google Workspace, add _spf.google.com to your SPF TXT record. Generate a DKIM key in the Google Admin console and add it as a TXT record in your DNS. Finally, create a _dmarc TXT record to define your DMARC policy and reporting addresses.

Organizations should always start with a p=none monitoring policy to collect aggregate reports and ensure legitimate emails are not inadvertently blocked. Once all legitimate senders are authenticated, transition to p=quarantine, and eventually p=reject for maximum security.

You can verify your configuration using free online DNS lookup tools or dedicated DMARC analyzers to check for syntax errors. Additionally, sending test emails to authentication verifier services will confirm if SPF, DKIM, and DMARC are actively passing.

DMARC alignment requires the From domain in the email header to match either the SPF Return-Path domain or the DKIM signing domain. This is crucial because it prevents attackers from using a valid SPF and DKIM setup on their own domain to spoof your corporate email address.

The most common mistake is exceeding the 10 DNS lookup limit, which causes legitimate SPF checks to fail. Organizations can fix this by auditing their SPF record, removing unused third-party senders, or using SPF flattening services to reduce the lookup count.

DMARC aggregate reports are XML files sent daily by receiving mail servers detailing the IP addresses sending emails on your behalf and their SPF and DKIM pass rates. You should monitor these reports to identify unauthorized spoofing attempts and fix misconfigured legitimate senders.

Yes, it is highly recommended to protect all domains, including parked or inactive domains, with a strict DMARC policy of p=reject. Attackers frequently exploit unprotected secondary domains to launch phishing attacks that appear linked to your organization.

Provide DNS record exports or screenshots from a DNS lookup tool showing the active SPF, DKIM, and DMARC TXT records for your organization's domains. Evidence of an active DMARC monitoring dashboard is also excellent proof of continuous compliance. Tools like WatchDog Security's Compliance Center can help centralize this evidence, record review dates, and keep auditor-ready documentation aligned to the control.

Teams often stall at DMARC p=none because they lack a clear plan to identify legitimate senders, resolve alignment issues, and prove readiness for p=quarantine or p=reject. Tools like WatchDog Security's Compliance Center can track the control requirements, assign tasks for each sending source (e.g., marketing, CRM, support), and maintain an evidence trail of policy changes and validation results.

Unapproved SaaS tools can send mail on a domain, creating SPF sprawl and DKIM/DMARC misalignment that weakens spoofing defenses. Tools like WatchDog Security's Asset Inventory can help catalog email-capable SaaS and services tied to identities and domains, making it easier to reconcile authorized senders and remove or reconfigure risky sources.