The short answer
MX records say where mail for your domain is delivered. SPF lists who may send as you, DKIM adds a signature proving a message was not altered, and DMARC tells receivers what to do when those checks fail. Mail goes to spam mostly when these are missing, wrong or not aligned with the From address.
Two jobs: receiving and proving
Email on your domain does two different things. Receiving: when someone writes to hello@yourcompany.com, their mail server looks up your MX record to find where to deliver it. Sending: when you write to someone, their mail server asks "is this really from yourcompany.com?" and checks three records to decide.
Those three are SPF, DKIM and DMARC. Each is a TXT record in your DNS. They exist because anyone can type any address in the From line of an email. Without checks, criminals could send as your domain, and receiving servers cannot tell the difference between them and you.
| Record | Plain meaning | Where it lives | If missing or wrong |
|---|---|---|---|
| MX | "Deliver mail for this domain to these servers." | Name: the bare domain. Several records with priority numbers. | Incoming mail bounces or vanishes. |
| SPF | "These servers are allowed to send mail as this domain." | TXT on the bare domain, starts with v=spf1 | Your mail is more likely to be marked as spam or rejected. |
| DKIM | "This message carries a digital signature, and here is the public key to check it." | TXT at selector._domainkey.yourdomain, for example google._domainkey | Messages cannot be verified as untampered. |
| DMARC | "If SPF and DKIM fail for my domain, do this, and send me reports." | TXT at _dmarc.yourdomain | Receivers decide on their own, and you see nothing about abuse. |
Example records, in plain terms
These are illustrations of the format. Your real values come from your email provider's setup page, so do not copy them literally.
- MX: priority 1, mail server name given by your provider. Google Workspace and Microsoft 365 each publish their own values.
- SPF: v=spf1 include:_spf.google.com ~all. This is the example format shown in Google's SPF guide. It means "Google's servers may send for this domain, and treat everything else as suspicious". Every service that sends mail as you (newsletter tool, invoicing tool, website form service) must be added to this one record.
- DKIM: a TXT record named google._domainkey with a value that begins v=DKIM1; k=rsa; p= followed by a long key. Google advises a 2048-bit key if your domain provider supports it, and some providers limit TXT record length.
- DMARC: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourcompany.com. The p tag is the policy, and rua is where daily summary reports are sent.
A domain should have a single SPF record. If you add a new sending service, edit the existing SPF record and add its include. Publishing a second SPF TXT record causes SPF to fail.
DMARC policies, and how to roll them out safely
Google's documentation describes three DMARC policies. With none, the message is delivered and the activity is logged in reports. With quarantine, failing messages are marked as spam. With reject, failing messages are rejected. Google recommends starting at none while you learn how receivers authenticate your mail, then moving to quarantine or reject, and using the pct tag to apply a stricter policy to a small share of messages first.
Before turning DMARC on, Google says SPF and DKIM should be set up and authenticating mail for at least 48 hours. Reports can be high in volume, so send them to a dedicated mailbox, a group or a reporting service instead of your personal inbox.
The trap: moving straight to reject before every legitimate sender is covered will block your own newsletter, invoices or form notifications. Go slowly, read the reports, fix each sender, then tighten.
Why legitimate mail goes to spam
Work through this list in order. Most cases are solved in the first three.
- 1SPF fails because a service that sends as you is not listed, or because two SPF records exist.
- 2DKIM is not set up for the sending service, or the DNS record was copied with a typo or a broken line.
- 3The From address does not match the domain that SPF or DKIM authenticated (this mismatch is called alignment). A form plugin sending "as" your domain through a general mail server is the classic case.
- 4A new domain or a new sending address with no history. Reputation builds slowly.
- 5The content looks like spam: all images, link shorteners, ALL CAPS subject lines, attachments from unknown senders.
- 6Complaints. Recipients marking your mail as spam damages your standing with providers.
- 7Your domain or server IP appears on a blocklist.
The Google and Yahoo bulk sender rules
If you send newsletters or other marketing email in volume, there are published rules. Google's sender guidelines say the requirements took effect on February 1, 2024. For bulk senders, defined as more than 5,000 messages a day, Google requires SPF, DKIM and DMARC on the sending domain, with a DMARC policy that can be set to none, plus one-click unsubscribe for marketing messages and a spam rate kept below 0.30% in Postmaster Tools. Google also recommends staying below 0.10%.
Yahoo's sender hub states that all senders need SPF or DKIM at minimum and a spam complaint rate below 0.3%. Bulk senders need both SPF and DKIM, a DMARC policy of at least none that passes, a working one-click unsubscribe, and unsubscribes honored within two days. Yahoo's page does not define the volume that counts as bulk.
For a small business sending ordinary business mail, the practical takeaway is simple: set up all three records, keep your complaint rate low, and make unsubscribing easy.
How to test
- 1Send a message from your domain to a Gmail address, open it, choose "Show original", and look for PASS next to SPF, DKIM and DMARC.
- 2Send a message to your own domain from an outside address and confirm it arrives. That tests MX.
- 3Use a free mail-tester or DNS lookup tool to view your published SPF, DKIM and DMARC records and check them for typos.
- 4Test every tool that sends as you: contact form notifications, invoicing, newsletter, CRM. Each can fail separately. See forms not sending emails for form-specific causes.
- 5Recheck after every DNS change. Google notes DKIM can take up to 48 hours to start working after you add a key, so test again the next day before you panic.
Example: The invoices that vanished
A consultancy started using an invoicing tool that sent messages as billing@theircompany.com. Clients stopped receiving invoices, and some reported them in spam. The domain had an SPF record for Google Workspace only. The invoicing tool's servers were not in it, and no DKIM was set up for the tool. The fix: add the tool's include to the existing SPF record (not a new record), publish the DKIM record the tool provided, and keep DMARC at p=none while watching reports. After a day the test messages showed PASS on SPF and DKIM and landed in inboxes. The cause was never the content of the invoices.
When to ask us
Send a request through the support form if mail stopped arriving, if messages are going to spam, or before you add a new sending tool. Include: your domain, who provides your email (Google Workspace, Microsoft 365 or other), an example of a message that failed (a link to the email headers or a screenshot, via Google Drive, Dropbox or Loom), the date it started, and anything changed in DNS recently. Do not send passwords. Our team will read your records and tell you what to change. If you are about to move the site, read what is DNS first so your mail records are not lost.
