If email from your domain keeps landing in spam or bouncing back outright, the most common culprit is a broken or missing authentication record. SPF, DKIM, and DMARC are three DNS-based checks that mailbox providers use to confirm a message really came from your domain. This guide walks you through how they relate to each other and how to track down which one is causing the problem.
Why these three checks matter together
It helps to think of SPF, DKIM, and DMARC as three checkpoints in a single line, not three unrelated tests. A message is evaluated against SPF first, then DKIM, and finally DMARC checks whether the domain in the visible "From" address lines up with whichever of the first two checks passed. Because of that order, a domain can have a perfectly valid DMARC record and still fail delivery if SPF or DKIM underneath it is broken. Understanding the order is the fastest way to figure out where to start looking.
Step 1: Read the failure signal you already have
Before changing anything in your DNS zone, look at what already told you something is wrong:
- A bounce message. The rejection text your mail server received back usually names the failing check directly, such as an SPF or DKIM failure versus a DMARC policy rejection.
- An inbox placement test. Sending a test message to a checker tool shows you whether it actually reached the inbox, the spam folder, or was blocked, across major providers like Gmail and Outlook.
- DMARC aggregate reports. If your DMARC record includes a reporting address, mailbox providers will periodically send you a summary showing every source sending mail as your domain and whether each one passed or failed. This is the most reliable way to catch problems you didn't know you had.
Step 2: Confirm each record actually exists
Run a DNS lookup for your domain (most domain registrars and hosting control panels, including your Avalon hosting control panel, include a DNS lookup or zone editor tool) and check for three things:
- A TXT record on your root domain that begins with the SPF version tag.
- A DKIM TXT record published at the selector subdomain your email platform uses.
- A DMARC TXT record at the special "_dmarc" subdomain of your domain.
If any of these come back empty, that's your starting point — an authentication layer that never runs can't be fixed further downstream.
Common SPF problems
SPF confirms that the server sending mail is actually authorized to do so for your domain. The most frequent issues are:
- No SPF record at all, which leaves every message from your domain looking unverified to the receiving server.
- Two SPF records on one domain. Mail standards only allow a single SPF record per domain; having two invalidates both and mail servers will treat SPF as broken.
- Too many lookups. SPF checking is capped at 10 DNS lookups. Records that reference many third-party services (a CRM, a marketing platform, a helpdesk) can quietly cross that limit and start failing outright.
- A missing sending service. If you add a new tool that sends email on your behalf — a support desk or newsletter platform, for example — and forget to add it to your SPF record, its mail will fail authentication even though everything else is set up correctly.
The fix in every case is the same: consolidate down to one clean SPF record that lists every legitimate sending source, published as a single TXT record. An example structure looks like this: v=spf1 include:mailprovider.example.com include:helpdesk.example.com -all — you would replace the include entries with the actual sending services your domain uses.
Common DKIM problems
DKIM attaches a digital signature to outgoing mail so the receiving server can confirm the message wasn't altered in transit and genuinely came from your domain. Typical issues include:
- No DKIM record published for the selector your sending platform uses, so the signature can never be verified.
- A selector mismatch — the signature references one selector name, but DNS has a record published under a different one.
- An outdated key length. Keys under 1024 bits are considered weak by modern standards; 2048 bits is now the recommended minimum.
Common DMARC problems
DMARC ties SPF and DKIM together by checking that the domain a recipient actually sees in the "From" field matches the domain that passed authentication, then tells receiving servers what to do with mail that fails that check.
- No DMARC record at all, which several major mailbox providers now treat as a red flag for bulk senders.
- A policy stuck on monitor-only. Many domains publish a DMARC record set to only monitor traffic and never advance it, which does nothing to actually stop fraudulent mail. Once your reports show all your legitimate senders passing, move the policy to quarantine and eventually reject.
- An alignment failure. SPF and DKIM can both individually pass while DMARC still fails, if the domain used behind the scenes doesn't match the domain your recipients see.
- No reporting address configured, meaning you get zero visibility into what's failing.
When your records are clean but mail still goes to spam
Authentication only proves you're allowed to send as your domain — it doesn't guarantee inbox placement on its own. Two other factors matter just as much: your domain's sending reputation (built from complaint rates, bounce rates, and recipient engagement over time) and its sending history. A brand-new domain with perfect DNS records still has no track record for mailbox providers to judge, so gradual, consistent sending volume matters alongside correct authentication.
Common issues checklist
- Exactly one SPF record exists, and every legitimate sender is included in it
- SPF stays under the 10-lookup limit
- A DKIM record is published for the correct, current selector
- DKIM keys are at least 2048 bits
- A DMARC record exists with a policy stronger than monitor-only, once you've confirmed legitimate senders pass
- DMARC includes a reporting address so you have visibility into failures
FAQ
Can I fix all three at once? Work through them in order — SPF, then DKIM, then DMARC — since later checks depend on the earlier ones passing.
How long until DNS changes take effect? Most changes propagate within 15–30 minutes, though it can take up to 48 hours in some cases, so wait before re-testing.
Where do I make these DNS changes? In your domain's DNS zone, which you can manage from your Avalon hosting control panel or your domain registrar if it's registered elsewhere.
