Why it matters
Email authentication fails quietly. SPF allows only 10 DNS lookups while checking a message, and every include costs at least one, plus whatever that provider's record includes in turn. Add a help desk and a newsletter tool to Google Workspace and you can pass the limit without noticing, at which point SPF fails for all your mail. DMARC adds a second trap: a message can pass SPF and still fail DMARC, because the domain that passed isn't the one in the From line.
This builder reads your records the way a receiving server does. It counts SPF lookups through the whole include tree, using the real records of 16 common senders read from DNS on the date shown, or records you paste. It lints SPF, DMARC and DKIM against their RFCs, reads the RSA key size straight from the DKIM key, and works out DMARC alignment for a sample message, so you can see why a newsletter sent through SendGrid passes only if it's DKIM-signed for your domain. The builder writes new records from the senders you tick.
How to use it
- Paste your SPF, DMARC and DKIM records.
- Paste any included record the snapshot doesn't have.
- Read the lookup count and the notes for each record.
- Try a sample message in the alignment check, then build new records.
FAQ
Why does SPF have a 10-lookup limit?
RFC 7208 caps DNS lookups so that checking one message can't flood DNS servers. Past 10, the result is a permanent error, which most receivers treat as a fail.
Can a message pass SPF but fail DMARC?
Yes. SPF checks the envelope sender (Return-Path), which is often your email provider's domain. DMARC needs that domain, or the DKIM signature's d= domain, to match your From domain.
Should I start DMARC at p=reject?
No. Start at p=none with rua reports, fix every legitimate sender, then move to quarantine and finally reject.
Does this look up my DNS?
No. It checks the records you paste, plus a dated snapshot of common providers' SPF records bundled with the page.
