Google and Microsoft Now Require DMARC: What You Need to Do

The New Email Authentication Mandates

Email authentication is no longer optional for organizations that send email at any meaningful scale. Google and Microsoft have both implemented mandatory email authentication requirements that affect every organization sending email to Gmail, Workspace, Outlook.com, and Microsoft 365 recipients.

Google's requirements, which began enforcement in phases through 2024 and 2025, mandate that all senders publish valid SPF or DKIM records, and that bulk senders (those sending more than 5,000 messages per day to Gmail addresses) must additionally implement DMARC with at least a p=none policy. Non-compliant messages face increased rejection rates, spam folder placement, and temporary errors (421 responses) during SMTP delivery.

Microsoft followed with its own enforcement beginning in May 2025, requiring SPF, DKIM, and DMARC for high-volume senders targeting Outlook.com, Hotmail, and Live.com. Microsoft's implementation routes non-compliant messages to the Junk folder initially, with outright rejection planned for subsequent enforcement phases.

The practical impact is straightforward: if your domain does not have properly configured email authentication, your messages will increasingly fail to reach recipients who use Gmail, Outlook, or any Microsoft 365-based email system. Given that these two providers collectively handle the majority of global email, the mandates effectively make email authentication a universal requirement.

Understanding SPF, DKIM, and DMARC

These three protocols work together to authenticate email and prevent spoofing. Each serves a distinct purpose, and our email authentication deep dive covers the underlying mechanics in detail.

SPF (Sender Policy Framework)

SPF lets you declare which mail servers are authorized to send email on behalf of your domain. It works through a DNS TXT record that lists allowed sending IP addresses and mechanisms.

example.com.  IN  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all"

This record says: Google Workspace servers, SendGrid servers, and the IP 203.0.113.10 are authorized to send email for example.com. The -all suffix means reject everything else.

When a receiving mail server gets a message claiming to be from your domain, it checks the connecting server's IP address against your SPF record. If the IP is not authorized, the message fails SPF.

Key limitation: SPF checks the envelope sender (MAIL FROM), not the visible "From" header that users see. An attacker can spoof the visible From address while using a different envelope sender that passes SPF. This is why SPF alone is insufficient.

DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to outgoing messages. Your mail server signs each message with a private key, and the corresponding public key is published in DNS. Receiving servers verify the signature to confirm the message was not altered in transit and that it originated from a server holding your private key.

selector1._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB..."

The DKIM signature is added as a header in the email:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1;
    h=from:to:subject:date:message-id;
    bh=abc123...;
    b=xyz789...

DKIM validates the message content and binds it to your domain. Unlike SPF, DKIM survives forwarding because the signature travels with the message.

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC ties SPF and DKIM together and adds two critical capabilities: alignment checking and reporting.

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensics@example.com; adkim=s; aspf=s"

Alignment means the domain in the visible "From" header must match the domain authenticated by SPF or DKIM. This closes the loophole where an attacker could pass SPF with their own domain while spoofing your domain in the From header.

Policy tells receiving servers what to do with messages that fail DMARC:

• p=none: Take no action, just report (monitoring mode)
• p=quarantine: Send failing messages to spam/junk
• p=reject: Block failing messages entirely

Reporting sends aggregate (rua) and forensic (ruf) reports back to you, showing who is sending email using your domain and whether those messages are passing or failing authentication.

The Current State of DMARC Adoption

Despite DMARC being available since 2012, adoption at enforcement levels remains remarkably low. Industry analyses consistently show that approximately 18-20% of domains have DMARC records set to enforcement (p=quarantine or p=reject). A significant portion of domains with DMARC records are still at p=none, which provides visibility through reporting but offers no protection against spoofing.

Common reasons for slow adoption include:

Complexity of email ecosystems. Modern organizations send email through numerous services -- their primary email platform, marketing automation, transactional email providers, CRM systems, helpdesk tools, and HR platforms. Each service must be accounted for in SPF and DKIM configuration before moving to enforcement. Missing a legitimate sender results in their email being quarantined or rejected.

Fear of breaking email delivery. Moving from p=none to p=reject is irreversible in its impact -- legitimate messages that fail alignment will be blocked. This fear leads organizations to stay at p=none indefinitely, gaining no protection.

SPF record complexity. The SPF specification limits DNS lookups to 10 per SPF evaluation. Organizations with many email-sending services frequently exceed this limit, causing SPF to fail entirely. Workarounds (SPF flattening, restructuring includes) add operational complexity.

Lack of ownership. Email authentication spans IT, marketing, sales, and HR teams. Without clear ownership, no single team drives implementation to completion.

Step-by-Step DMARC Implementation

A safe, methodical approach to DMARC implementation minimizes risk while progressing toward full enforcement.

Phase 1: Inventory and SPF (Week 1-2)

Start by identifying every service that sends email using your domain. Check with marketing (email campaigns, automation), sales (CRM), support (helpdesk), HR (onboarding, payroll), IT (system notifications), and development (transactional email).

Publish or update your SPF record to include all identified senders:

example.com.  IN  TXT  "v=spf1 include:_spf.google.com include:amazonses.com include:sendgrid.net -all"

Verify your SPF record does not exceed the 10-lookup limit. Each include and redirect mechanism counts as one lookup. Use ip4 and ip6 mechanisms (which do not count as lookups) where possible. Our SPF record configuration guide walks through lookup counting and flattening techniques.

Phase 2: DKIM Signing (Week 2-3)

Enable DKIM signing on every service that sends email as your domain. Each service typically provides instructions for publishing a DKIM public key in your DNS. You will end up with multiple DKIM selectors:

google._domainkey.example.com.     IN  TXT  "v=DKIM1; k=rsa; p=..."
ses._domainkey.example.com.        IN  TXT  "v=DKIM1; k=rsa; p=..."
sg._domainkey.example.com.         IN  TXT  "v=DKIM1; k=rsa; p=..."

Verify signing is active by checking outbound message headers for valid DKIM-Signature headers. See the DKIM, MTA-STS, and TLS-RPT setup guide for provider-specific instructions and key rotation best practices.

Phase 3: DMARC Monitoring (Week 3-4)

Publish a DMARC record at p=none with reporting enabled:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100"

Collect aggregate reports for at least 2-4 weeks. Analyze the reports to identify:

• Legitimate senders that are passing DMARC (good)
• Legitimate senders that are failing DMARC (need fixing)
• Unauthorized senders spoofing your domain (the threat DMARC protects against)

DMARC aggregate reports arrive as XML files. Use a DMARC reporting service or parse them to understand your email flows.

Phase 4: Fix Alignment Issues (Week 4-6)

Address any legitimate senders that are failing DMARC alignment. Common fixes:

• Configure the service to send with DKIM alignment to your domain
• Add the service's sending IPs to your SPF record
• Have the service use a subdomain (e.g., mail.example.com) with its own SPF and DKIM, and set a subdomain DMARC policy

Phase 5: Move to Enforcement (Week 6-8)

Once reports show all legitimate email passing DMARC, progressively tighten the policy. Our DMARC policy enforcement guide details the pct ramp-up strategy and common pitfalls at each stage.

# Step 1: Quarantine 10% of failures (test the waters)
_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@example.com"

# Step 2: Quarantine 50% (expand coverage)
_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc-reports@example.com"

# Step 3: Quarantine 100% (full quarantine)
_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@example.com"

# Step 4: Reject (full protection)
_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

The pct tag lets you apply the policy to a percentage of failing messages, providing a gradual rollout.

Common DMARC Pitfalls

Several recurring issues trip up organizations during DMARC implementation.

SPF exceeding 10 DNS lookups. Each include, a, mx, and redirect mechanism triggers a DNS lookup. Nested includes count toward the limit. A single include:_spf.google.com can consume 3-4 lookups of your 10-lookup budget. Exceeding the limit causes SPF to return permerror, which means SPF effectively fails for all messages.

To diagnose, count your lookups:

# Check your SPF record
dig +short TXT example.com | grep spf

# Recursively count includes
dig +short TXT _spf.google.com
# Each include here adds to your count

Mitigations include using ip4/ip6 mechanisms (zero lookups) instead of include where possible, consolidating email services, or implementing SPF flattening.

Third-party services breaking alignment. When a marketing platform sends email "from" your domain but uses its own envelope sender (e.g., bounce.mailservice.com), SPF passes for the service's domain, not yours. DMARC alignment fails because the authenticated domain does not match your From header domain. The fix is configuring the service to use your domain in the envelope sender or ensuring DKIM alignment instead.

Subdomain policy gaps. DMARC's sp tag controls the policy for subdomains. If you set p=reject but do not set sp=reject, subdomains may inherit a weaker policy or default to none, allowing attackers to spoof subdomains like billing.example.com.

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@example.com"

Missing DKIM signing on transactional services. Many organizations properly configure DKIM for their primary email platform but forget to enable it for transactional email services (password resets, order confirmations, system alerts). These messages fail DKIM alignment and may be quarantined or rejected under enforcement.

Forward and mailing list breakage. Email forwarding (e.g., university alumni forwarding, mailing lists) can break both SPF and DKIM. SPF fails because the forwarding server's IP is not in your SPF record. DKIM may survive if the message is not modified, but mailing lists that add footers or modify subject lines break DKIM signatures. ARC (Authenticated Received Chain) is the emerging solution, but adoption is still growing.

How CyberShield Validates Email Authentication

CyberShield's email authentication modules check every layer of the authentication stack during a domain scan.

SPF validation retrieves and parses your SPF record, checking for syntactic validity, the use of -all (hard fail) vs ~all (soft fail) or +all (allow all -- a critical misconfiguration), and whether the record exceeds the 10-lookup limit. CyberShield flags ~all as a medium finding because it provides weak enforcement, and +all as critical because it disables SPF protection entirely.

DKIM presence checking looks for DKIM selectors associated with common email providers. While DKIM configuration is primarily validated through actual message signing rather than DNS alone, CyberShield checks that the expected DKIM public key records are published and parseable.

DMARC policy evaluation examines your DMARC record for policy strength (p=none vs p=quarantine vs p=reject), subdomain policy (sp tag), percentage coverage (pct tag), and reporting configuration (rua and ruf tags). A p=none DMARC record is flagged because it provides monitoring but no protection.

MTA-STS checking verifies whether your domain publishes an MTA-STS policy that enforces TLS for inbound email delivery. MTA-STS prevents downgrade attacks where an attacker intercepts SMTP connections and strips TLS encryption.

TLS-RPT validation checks for a TLS reporting record (_smtp._tls.example.com) that receives reports about TLS failures in email delivery to your domain.

Action Plan for Compliance

If you have not yet implemented email authentication, here is the prioritized path to compliance with both Google and Microsoft requirements:

This week: Publish or verify your SPF record. Ensure it includes all services that send email as your domain and ends with -all. Publish a DMARC record at p=none with reporting to start collecting data.

Within 2 weeks: Enable DKIM signing on all email-sending services. Verify signatures by checking outbound message headers.

Within 4 weeks: Review DMARC aggregate reports. Identify and fix any legitimate senders failing alignment. Address SPF lookup count if it exceeds 10.

Within 6 weeks: Move DMARC to p=quarantine with pct=25, gradually increasing to pct=100 as reports confirm legitimate email is passing.

Within 8 weeks: Move DMARC to p=reject. Add sp=reject for subdomain protection. Deploy MTA-STS for inbound email TLS enforcement.

Ongoing: Monitor DMARC reports for new services that need authentication configuration. Run CyberShield scans regularly to verify your email authentication remains properly configured. Review authentication when onboarding new email-sending services.

The organizations that implement email authentication now are not just meeting Google and Microsoft requirements -- they are protecting their brand, their employees, and their customers from the email spoofing attacks that drive phishing, business email compromise, and credential theft.