Email Infrastructure Footguns¶

Misconfigurations that send your email to spam, destroy your domain reputation, or let attackers impersonate you.

1. Starting with `p=reject` DMARC Without Monitoring First¶

You add a DMARC record with p=reject on day one to "be secure." Legitimate email from your CRM, marketing platform, IT ticketing system, and automated alerts all fail DMARC because they were never configured with your SPF/DKIM. All of it gets rejected at receiving servers. Users stop receiving notifications. The helpdesk is flooded.

Fix: Always start with p=none and a rua= address. Monitor DMARC aggregate reports for at least two weeks to identify every IP and service sending as your domain. Only move to quarantine then reject after all legitimate senders are covered.

2. Exceeding the SPF 10-Lookup Limit¶

Your SPF record has grown over years: include:mailchimp.net include:sendgrid.net include:_spf.google.com include:salesforce.com mx. Each include: itself resolves to more lookups. The total exceeds 10. Receiving servers return SPF PermError, which many treat as a neutral or fail result. Your SPF record silently stops providing any protection or authorization.

Fix: Audit lookup count regularly using spfwalk. Replace include: entries with explicit ip4: ranges where the sending service's IP ranges are stable (Google, AWS SES, SendGrid all publish CIDR lists). Remove include: entries for services you no longer use.

Under the hood: The 10-lookup limit is defined in RFC 7208, Section 4.6.4. Each include:, a:, mx:, redirect=, and exists: counts as a DNS lookup. ip4: and ip6: mechanisms do NOT count because they require no DNS resolution. Nested include: records count recursively — if include:_spf.google.com itself resolves to 3 more lookups, that's 4 total. Use dig txt _spf.google.com to trace the chain.

3. Using `~all` (Softfail) Instead of `-all` (Hard Fail) Forever¶

You deploy SPF with ~all as a "safe" starting point and forget to move to -all. ~all tells receiving servers that mail from unlisted IPs is suspicious — but still deliver it. Spammers spoofing your domain get through. ~all provides minimal actual protection.

Fix: After confirming your SPF record covers all legitimate senders (use DMARC aggregate reports), change ~all to -all. This is a hard rejection of mail from unlisted sources. The time to make this change is typically within 4-6 weeks of initial deployment.

Gotcha: Gmail's 2024 sender requirements mandate that bulk senders (5,000+ messages/day to Gmail) must have both SPF and DKIM passing with DMARC alignment. ~all technically passes SPF but signals low confidence. While Gmail won't reject based on ~all alone, their spam scoring penalizes it, and the new requirements push everyone toward explicit -all enforcement.

4. Rotating DKIM Keys Without Updating the DNS Record¶

You rotate the DKIM private key on your mail server (good security practice) but forget to update the corresponding public key in DNS. For the TTL of the old DNS record (could be 24 hours), outgoing signatures fail to validate — the private key signs with the new key, but verifiers look up the old public key in DNS. DMARC fails for all outbound mail during this window.

Fix: Use a new selector name for each key rotation (e.g., mail202601._domainkey). Publish the new DNS record first and wait for the TTL to propagate, then switch the signing key to the new private key, then retire the old selector after another TTL period. Never overwrite an existing selector's public key in DNS.

5. Sending Transactional Email from a Shared IP Without Warming¶

You launch a new product and immediately send 50,000 welcome emails from a fresh EC2 elastic IP. Major ISPs have no reputation data for this IP. Gmail, Yahoo, and Outlook rate-limit or block the messages. Users never get their welcome emails. You've also damaged the IP's reputation by sending high volume before it's established.

Fix: Warm the IP gradually: start with a few hundred messages per day, double every few days, target your most engaged users first (users who actively signed up and have high open probability). Or use a transactional email service (SES, SendGrid, Postmark) that manages IP warming and maintains pre-warmed shared IP pools.

6. Configuring DKIM for `example.com` but Sending from `noreply@app.example.com`¶

DKIM's d= domain must match (or be a parent of, in relaxed alignment) the From: header domain. You configure DKIM for example.com but your application sends From: noreply@app.example.com. In strict alignment mode, this fails. Even in relaxed mode, if the d= is example.com and From: is app.example.com, it may pass — but you also need SPF for app.example.com and a DMARC record for that subdomain.

Fix: Configure DKIM for every domain and subdomain you send from. Set up _dmarc.app.example.com or use sp= on the parent DMARC record to govern subdomain policy. Document all sending subdomains in your email authentication matrix.

7. Not Setting a PTR Record for the Sending IP¶

Your mail server has no PTR (reverse DNS) record. Many receiving mail servers check PTR as a basic spam signal. Microsoft 365 and some ISPs will reject mail from IPs with no PTR. Even when not outright rejected, missing PTR increases spam scoring.

Fix: Set a PTR record for every mail server IP that resolves to a meaningful hostname (ideally related to your domain). Verify with dig -x <ip> +short. PTR records are set by your IP space owner — for cloud providers, this is done in the console (AWS: Elastic IP → PTR; GCP: Reserve static external IP → PTR; Azure: Public IP → DNS name label).

8. Accepting Forwarded Mail Breaks DMARC¶

You run a department mailing list using a simple forwarder. The forwarder rewrites the envelope From: to its own domain, but the message body and DKIM signature are untouched. The DKIM signature over the body now doesn't match (the forwarder may have altered headers). SPF fails because mail now comes from the forwarder's IP, not the original sender's authorized IP. DMARC fails for both. If your DMARC policy is p=reject, every forwarded message is rejected at the final recipient.

Fix: Switch mailing lists to a proper MLM that re-sends (breaks and re-signs with its own DKIM) or enable ARC on the forwarder. If you control the receiving domain, configure it to honor ARC chains. Consider using a purpose-built mailing list service rather than a simple server-side forwarder.

9. Ignoring Bounce and Complaint Rates¶

Your bounce rate climbs above 5% because you're sending to old email addresses. Gmail and Yahoo now return spam complaints directly via feedback loops. You're not processing these signals. Your domain and IP reputation deteriorates silently. Six weeks later, all your email goes to spam — even to active, engaged users who want the email.

Fix: Implement list hygiene: hard-bounce addresses (550 = permanent failure) must be unsubscribed immediately and never retried. Soft bounces (421, 450 = temporary) can be retried a limited number of times before removal. Monitor complaint rates in Google Postmaster Tools and Yahoo Postmaster. ISPs expect complaint rates below 0.1%.

10. Sending With a `From:` Domain That Has No DMARC Record¶

Without a DMARC record, receiving servers have no policy guidance for what to do with messages that fail SPF or DKIM. Some treat this as permissive. Attackers can spoof your domain and send phishing emails with no consequences. Meanwhile, legitimate mis-configured mail from your own services also passes unchecked.

Fix: Every domain that sends email (and every domain that doesn't send email, to prevent spoofing) should have a DMARC record. For non-sending domains: v=DMARC1; p=reject;. For sending domains: start with p=none and a rua= address, then graduate to enforcement.

War story: In 2020, attackers exploited the lack of DMARC on numerous US government agency subdomains to send COVID-19 phishing emails that appeared to come from .gov addresses. CISA's Binding Operational Directive 18-01 had required DMARC on all federal domains, but many subdomains were missed. A _dmarc.subdomain.example.gov record with p=reject would have prevented delivery of spoofed messages from those subdomains.

11. Putting DMARC Reporting Address on the Same Server You're Configuring¶

You set rua=mailto:dmarc@example.com on a brand-new mail server, before the DMARC record is properly configured. The DMARC report delivery to dmarc@example.com itself triggers DMARC checks, which may fail, which generates another report — or the reports simply don't arrive because the mail server delivering them rejects them due to the misconfigured state you're trying to diagnose.

Fix: Use a dedicated DMARC report collection address on a fully operational separate mail service (e.g., dmarc-reports@gmail.com for small setups, or a purpose-built service like Postmark's DMARC reporting). Alternatively, use a third-party DMARC monitoring service that has its own infrastructure.

12. Not Including All Third-Party Senders in SPF Before Moving to DMARC Enforcement¶

Marketing uses Mailchimp. Sales uses Salesforce. The helpdesk uses Zendesk. IT uses Microsoft 365 for internal notifications. Developers use Amazon SES for the application. None of these are in your SPF record when you move DMARC to p=reject. All legitimate business email fails.

Fix: DMARC aggregate reports are the ground truth for who sends as your domain. Run p=none with rua= for at least 30 days before enforcement. Parse every aggregate report. For each source IP that is legitimate, add it to SPF (or add include: for the service's SPF macro). Only move to enforcement when the aggregate reports show >95% of mail passing SPF or DKIM alignment.