SPF, DKIM and DMARC get bundled together so often that plenty of domain owners assume they are three parts of one system. They are not. Each one inspects a different part of an email, and each one can pass or fail independently of the others. That matters because the most common support ticket in this space sounds like: “SPF passes, so why is my mail landing in spam?” The answer usually sits in the gap between what SPF checks and what DMARC actually requires. Here is what each record really does, in plain terms.
SPF checks the envelope sender, not the address your recipient sees
SPF, Sender Policy Framework, is a DNS TXT record that lists which servers are allowed to send mail for a domain. When a receiving server gets a message, it reads the envelope sender, also called the Return-Path or MAIL FROM address, pulls the domain from that address, looks up the SPF record, and checks whether the connecting IP is on the approved list. The result is one of a handful of verdicts: pass, fail, softfail, neutral, none, permerror or temperror. Simple enough. The myth is that SPF protects the From header your recipient sees in their inbox. It does not. SPF never looks at that header at all.
This is where things get interesting. The envelope sender and the visible From address are two separate fields, and they are allowed to differ. A mailing list, a helpdesk ticketing system or a marketing platform can send mail with an envelope domain of bounces.provider.example while the From header reads you@yourdomain.com. SPF validates the bounce domain, passes cleanly, and the receiving server still has no idea whether yourdomain.com authorized the message. That is the hole DMARC was built to close, and it is why a message can sail through SPF and still fail DMARC. The envelope domain and the From domain never lined up in the first place.
One more detail worth knowing: SPF has a 10-DNS-lookup limit. Every include, a, mx, ptr, exists and redirect mechanism in the record counts toward it. Domains that stack four or five third-party senders often blow past the limit and return a permerror, which receivers treat as no SPF at all. If your record has grown into a wall of includes, that is a sign to consolidate senders or move to a subdomain-per-sender setup rather than keep bolting on more lookups.
DKIM signs the message so tampering becomes visible
DKIM, DomainKeys Identified Mail, attaches a cryptographic signature to the message. The sending server hashes selected headers and the body, signs the hash with a private key, and stamps the result into a DKIM-Signature header. The matching public key sits in DNS at a selector you choose, something like selector1._domainkey.yourdomain.com. The receiving server fetches that key, recomputes the hash and compares. If anything in the signed portion changed in transit, the signature breaks.
DKIM has one big advantage over SPF: it survives forwarding. When a message gets relayed, the envelope sender often changes, which can break SPF, but the signature travels with the message and still verifies as long as the signed headers and body stay intact. That is why forwarders and mailing lists tend to cause SPF failures but leave DKIM alone. The signature also carries a d= tag that names the signing domain, and that tag is what DMARC later compares against the From header. Sign with your own domain, not your ESP’s shared domain, or the alignment check will not do you any favors.
Why key length and rotation still matter
Most providers default to 1024-bit keys, and 2048-bit is the better choice where your DNS can handle it, since a longer TXT record can trip the 512-byte UDP limit and force a TCP retry. Rotate keys periodically and keep the old public key published during the overlap so in-flight messages do not fail verification. A stale key left in DNS for years is a quiet liability, not a convenience.
DMARC ties SPF and DKIM back to the From header
DMARC, Domain-based Message Authentication, Reporting and Conformance, is the policy layer. It does not authenticate anything on its own. What it does is require that at least one of SPF or DKIM pass and that the passing domain align with the domain in the From header. what is catch-all email is worth a closer look. Alignment can be strict, an exact match, or relaxed, where the organizational domain matches. So if SPF passes on bounces.provider.example but the From domain is yourdomain.com, alignment fails. If DKIM passes with d=yourdomain.com, DMARC passes. That single rule explains most of the confusing results people see in their authentication reports.
The DMARC record also tells receivers what to do when both checks fail: p=none asks for monitoring only, p=quarantine asks for spam folder treatment, and p=reject asks for outright refusal. Start at none, collect reports at the address in your rua= tag, and watch the XML for a few weeks before tightening the policy. You will see legitimate senders you forgot about, and you will see spoofing attempts you did not know were happening. Moving straight to reject without that data is how people break their own invoice mail.
Reports are the underrated part. Aggregate reports arrive daily as XML attachments, and they show you every IP sending mail as your domain, whether it passed, and which SPF or DKIM result it produced. Reading them is tedious, but the first month usually turns up at least one forgotten application sending mail through a host you never authorized. That is the whole point of a monitoring phase.
Catch-all domains and the authentication myths that follow them
Here is a myth that refuses to die: that a catch-all mailbox somehow weakens or strengthens SPF, DKIM or DMARC. It does neither. A catch-all email address accepts every message sent to a domain, including mail addressed to local parts that do not exist. A standard mail server replies with 550 no such user when no mailbox matches, and the catch-all rule replaces that failed address lookup branch so the message lands in one collection point instead of bouncing. All of that happens after authentication. SPF, DKIM and DMARC govern outbound mail authentication and inbound acceptance checks, and none of them care whether the recipient address is real.
The catch-all is configured on the mail server, not DNS. MX records route inbound mail to a mail server, and MX host priority decides which server gets tried first, but the decision to accept an unknown recipient is a local setting in Postfix, Exim, Dovecot or whatever stack you run. A catch-all setup requires DNS pointing at the right host and a server configured to accept unknown recipients. Get the DNS right and skip the server setting, and you will still see 550 no such user. Flip the server setting on and forget the DNS, and nothing arrives at all.
People also confuse a catch-all with its neighbors. A catch-all differs from an alias, forwarding and disposable addresses. An alias maps one specific address to another mailbox. Forwarding relays mail to an external destination. Throwaway addresses are generated per signup and discarded. A catch-all mailbox collects all unmatched addresses in one place, which is convenient for recovering typos in your own domain and spotting mail sent to invented addresses. That last part is also the risk: catch-all domains carry risks of spam to invented addresses, because scrapers guess info@, sales@ and admin@ and every guess lands in the same inbox. Filter aggressively or skip the catch-all entirely if nobody will read it.
None of this touches your authentication records, but the two topics collide in one practical way. If you run a catch-all, you will receive bounce messages and reports for addresses you never created, and some of those will be DMARC aggregate reports for subdomains you forgot existed. A catch-all can be a useful backstop for that reporting traffic. It will not fix a misaligned DKIM signature, though, and no amount of server-side acceptance rules will.
Set up all three records, then verify them from the outside. Send a test message through every system that sends as your domain, check the Authentication-Results header at the receiving end, and confirm that SPF, DKIM and DMARC each show pass with your domain aligned. Publish DMARC at p=none first, read the reports for a month, fix the senders that fail alignment, then move to quarantine and eventually reject. If you use a hosted provider such as AllMail, confirm which domain it signs with before you assume DKIM alignment is handled. The records are cheap to publish and the reports are free to read, and the payoff is that receivers can finally tell your real mail apart from someone else’s spoof.