Why Your Emails Land in Spam: Moving to Strict DMARC (p=reject) Without Breaking Inbound Delivery

Why Good Emails End Up in Spam

If you run transactional email for a product—password resets, billing receipts, team invites—you have probably watched delivery rates drop mysteriously at some point.

In early 2024, Google and Yahoo raised the floor for bulk and transactional senders. They stopped treating SPF and DKIM as optional suggestions and began aggressively rejecting unaligned or poorly authenticated mail. But even teams that think they did everything right frequently get tripped up by DNS subtleties that standard tutorials never mention.

Let's walk through what mail servers actually look for when receiving your email, why p=none does not protect you, and how to safely enforce p=reject without accidentally blocking your own receipts.

1. The Three Layers of Mail Authentication

Before touching your DNS records, you need a crystal-clear mental model of the three protocols and how they interact:

1. SPF (Sender Policy Framework): A TXT record on your domain listing which server IP addresses are authorized to send mail on your behalf.
2. DKIM (DomainKeys Identified Mail): A cryptographic signature added to the email headers by your mail server, verified against a public key published in your DNS.
3. DMARC (Domain-based Message Authentication, Reporting, and Conformance): A policy telling receiving servers what to do if an email claims to come from your domain but fails SPF or DKIM checks.

The common misconception is that passing SPF or DKIM is enough. DMARC requires alignment: the domain in the visible From: header that the user sees must match the domain authenticated by SPF or DKIM.

2. The Silent Trap: The 10-Lookup SPF Limit

RFC 7208 strictly mandates that an SPF check cannot exceed 10 DNS lookups. Every time your SPF record includes an external service (include:_spf.google.com, include:sendgrid.net, include:mailgun.org), the receiving mail server makes one or more recursive DNS queries.

If you have connected Google Workspace, Zendesk, a marketing tool, and a transactional provider like Resend or Postmark, your SPF record might look like this:

v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org include:servers.mcsv.net -all

When evaluated recursively, this record requires 12 DNS queries. Because that exceeds the limit of 10, receiving servers immediately evaluate the check as PermError. To Gmail and Outlook, a PermError is treated almost like a hard fail, dumping your transactional messages straight into the spam folder.

How to solve this:

• Prune unused third-party services: Audit every include: regularly. If you migrated away from SendGrid 6 months ago, remove its include immediately.
• Rely primarily on DKIM alignment: DMARC passes if either SPF or DKIM is aligned. Forwarded emails inevitably fail SPF anyway because the forwarding server's IP is not in your SPF record. DKIM signatures, however, survive mail forwarding untouched.

3. The Illusion of p=none

Most teams create a DMARC record and leave it at:

_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com"

The p=none policy is strictly monitoring mode. It tells Gmail, "If someone spoofs my domain, let the email through anyway, just email me a report." It provides zero phishing protection and tells mailbox providers that your security posture is unverified.

To gain full inbox trust and prevent spoofing of your brand, you must progress to p=reject.

4. The Safe 3-Step Rollout to p=reject

Enforcing p=reject blindly on day one can accidentally discard emails from obscure services (like your accounting software or automated cron alerts). Follow this graduated migration path instead:

Step 1: Collect Aggregate Telemetry (14 Days)

Publish a monitoring record with an aggregate report mailbox (rua):

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

Inspect the daily XML reports. Identify every IP address sending mail using your domain. If you find legitimate outbound traffic failing DKIM (for instance, an internal notification script), generate dedicated 2048-bit DKIM keys for that service.

Step 2: Quarantine Phase (7 Days)

Move to quarantine at a partial percentage. Any unauthenticated mail will be diverted to spam rather than silently rejected:

_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc-reports@yourdomain.com"

Verify that no legitimate user reports missing emails. Gradually bump pct=50 to pct=100.

Step 3: Full Rejection (Permanent)

Lock the door completely:

_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=reject; sp=reject; pct=100; adkim=s; aspf=s; rua=mailto:dmarc-reports@yourdomain.com"

• p=reject: Drop any non-compliant mail sent from your apex domain.
• sp=reject: Apply the same strict policy to any subdomains.
• adkim=s & aspf=s: Require strict alignment (no loose subdomain matching).

5. Adding BIMI and TLS-RPT for Extra Trust

Once you have a verified p=reject policy in place, two low-hanging optimizations yield immediate reputation gains:

1. BIMI (Brand Indicators for Message Identification): Displays your verified SVG logo next to incoming messages in Gmail and Apple Mail, visibly distinguishing your emails from spam.
2. TLS-RPT (SMTP TLS Reporting): A simple TXT record at _smtp._tls.yourdomain.com requesting reports on MTA-STS encryption delivery failures.

Setting up email deliverability is not glamorous, but once your domain is cryptographically sealed, you will never have to explain to a client why their invoice or activation code vanished into the junk folder.