SPF, DKIM and DMARC: Why Your Website Emails Land in Spam

By Jacob Campbell · Published November 12, 2026 · Updated November 12, 2026 · 🛡️ Security · 9 min read

Key facts

• 5,000+ a day — The volume at which Gmail's stricter bulk-sender rules, including DMARC, apply
• 0.3% — The spam-complaint rate Gmail and Yahoo tell senders to stay below
• 10 — The maximum DNS lookups an SPF check may make before it returns an error
• 1 — SPF records allowed per domain; two records means SPF fails

What SPF, DKIM and DMARC each prove

Each record answers a different question for the receiving server.

• SPF (Sender Policy Framework) is a TXT record on your domain that lists the servers allowed to send mail for it. It is defined in RFC 7208. The receiver checks the server that handed over the message against that list. SPF checks the envelope sender (the bounce or Return-Path address), not the From address your customer sees.
• DKIM (DomainKeys Identified Mail), defined in RFC 6376, adds a cryptographic signature to each message. The signature names a signing domain (d=) and a selector (s=), and the receiver fetches the public key from DNS at selector._domainkey.yourdomain.com. If the signature checks out, the message was not altered and the signing domain took responsibility for it.
• DMARC, published at _dmarc.yourdomain.com, ties the two to the From address people actually read. A message passes DMARC when SPF or DKIM passes and the domain that passed is aligned with the From domain. DMARC also tells receivers what to do with mail that fails (p=none, quarantine or reject) and where to send reports (rua=).

Alignment is the part people miss. A form plugin can pass SPF using the hosting company's own bounce domain and still fail DMARC, because that domain is not yours. Under the default relaxed alignment, a subdomain such as mail.yourdomain.com counts as aligned with yourdomain.com; strict alignment (aspf=s or adkim=s) requires an exact match.

One note on the standard itself: the RFC Editor's page for RFC 7489, the original DMARC specification, now marks it as obsoleted by RFCs 9989, 9990 and 9991. If your DNS host or email provider has updated its DMARC guidance, follow its current documentation for any tag changes.

What Gmail, Yahoo and Outlook.com require

Google's Email sender guidelines split senders into two groups. Everyone sending to Gmail must set up SPF or DKIM, have valid forward and reverse DNS for their sending IPs, use TLS, keep the spam rate in Postmaster Tools below 0.3%, and format messages to RFC 5322. Google also notes that sending to personal Gmail accounts needs a DKIM key of at least 1024 bits, and it recommends 2048.

Senders of more than 5,000 messages a day to Gmail must also set up both SPF and DKIM, publish a DMARC record (a policy of p=none is enough), align the From domain with the SPF or DKIM domain, and support one-click unsubscribe for marketing and subscribed mail.

Yahoo's sender best practices say the same in outline: all senders must implement SPF or DKIM and keep complaints under 0.3%, and Yahoo "strongly urges all senders to publish a DMARC policy". Bulk senders need SPF and DKIM, a DMARC policy of at least p=none that passes, an aligned From domain, a working one-click List-Unsubscribe header and unsubscribes honoured within two days.

Microsoft announced that domains sending more than 5,000 emails a day to Outlook.com consumer addresses must pass SPF and DKIM and have a DMARC policy of at least p=none aligned with one of them. Its April 2025 update said non-compliant mail would be rejected from 5 May 2025 with the error 550; 5.7.515.

Most small businesses send far fewer than 5,000 emails a day, so the strict rules do not formally apply. They are still the clearest public description of what receivers trust, and meeting them costs a few DNS records.

Why contact-form emails fail: the common mistakes

1. Putting the visitor's address in the From header

Many forms send the enquiry "from" whatever address the visitor typed. Your web server is not authorised to send for gmail.com or the visitor's company domain, so SPF and DKIM cannot align with that From address, and the visitor's domain's own DMARC policy may tell the receiver to quarantine or reject it. Google's guidelines also say not to impersonate Gmail From headers. The fix is simple: send from an address on your domain (for example [email protected]) and put the visitor's address in Reply-To, so pressing reply still reaches them.

2. Sending with PHP mail() from shared hosting

PHP's mail() hands the message to the server's local mail program. On shared hosting that usually means the host's server, which may not be listed in your SPF record and may not sign with your DKIM key. The envelope sender can default to a server account, which breaks SPF alignment. The PHP manual shows how to set the envelope sender with the -f parameter, and it notes that mail() is not suited to larger volumes. The more reliable route is to send through authenticated SMTP or an API from your mailbox provider or a transactional email service that signs with DKIM for your domain.

3. Two SPF records, or too many lookups

Each new service tells you to "add our SPF record", and people add a second v=spf1 TXT record. RFC 7208 does not allow multiple SPF records for one name; the result is a permanent error, so SPF fails for everyone. Merge them into a single record. The same RFC caps the mechanisms that trigger DNS lookups (include, a, mx, ptr, exists and redirect) at 10 per check. Go over that and SPF returns an error. ip4, ip6 and all do not count.

4. DKIM switched on for the mailbox but not for the website's sender

Your Google Workspace or Microsoft 365 mail may be signed while the form's mail, sent by a different service, is not. Every service that sends as your domain needs its own DKIM setup, usually a CNAME or TXT record it gives you under its own selector.

A safe order for setting it up

1. List every sender. Write down everything that sends email as your domain: your mailbox provider, the website or form plugin, your shop or booking system, invoicing and newsletter tools.
2. Publish one SPF record. Combine the include: values each provider documents into one TXT record at the root of your domain, for example v=spf1 include:_spf.google.com include:sendprovider.example ~all. RFC 7208 describes ~all as softfail ("probably not authorised") and -all as fail. Many teams start with ~all and tighten once reports look clean.
3. Turn on DKIM for each sender. Add the selector records each provider gives you and switch signing on in its dashboard. Use a 2048-bit key where you have the choice.
4. Wait, then add DMARC in monitoring mode. Google's recommended rollout says to set up SPF and DKIM at least 48 hours before DMARC, then start with a record such as v=DMARC1; p=none; rua=mailto:[email protected] and review reports for about a week.
5. Read the reports. Aggregate reports show which servers sent mail as your domain and whether each passed SPF, DKIM and alignment. Anything legitimate that fails needs fixing at step 2 or 3 before you go further.
6. Tighten gradually. Google suggests moving to p=quarantine for a small percentage first, for example v=DMARC1; p=quarantine; pct=5; rua=mailto:[email protected], raising the percentage as reports stay clean. p=reject blocks failing mail entirely, so treat it as the last step, not the first.

Change one thing at a time and keep a note of the old record before you edit it. DNS changes are easy to make and easy to undo, as long as you know what was there.

How to check it is working

Send a test enquiry through your own contact form to a Gmail address and an Outlook.com address. In Gmail, open the message, choose Show original and look for SPF: PASS, DKIM: PASS and DMARC: PASS. Check that the DKIM domain and the From domain are yours, not your host's.

• If SPF passes but DMARC fails, the passing domain is not aligned. Look at the Return-Path and the DKIM d= value.
• If DKIM is missing, signing is not switched on for the service that sent that message.
• If nothing arrives at all, check the form's own error log and your sending service's activity log before blaming DNS.

Repeat the test after any change to hosting, form plugins or email providers. Those moves are when authentication most often breaks quietly, and a monthly test enquiry belongs on any maintenance checklist.

Sources

• Google: Email sender guidelines
• Google Workspace: Recommended DMARC rollout
• Yahoo Sender Hub: Best practices
• Microsoft Tech Community: Outlook's new requirements for high-volume senders
• RFC 7208: Sender Policy Framework (SPF)
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• PHP Manual: mail()

Related reading

• Contact form spam protection — Honeypots, Turnstile and reCAPTCHA: stop junk coming in before you fix what goes out.
• Connect a custom domain: DNS and SSL — Where DNS records live and how to edit TXT and CNAME records safely.
• Website maintenance guide — The routine checks, including test enquiries, that keep a site's forms working.

Frequently asked questions

Do I need DMARC if I only send a few emails a day?

Gmail and Yahoo only require DMARC for bulk senders, but Yahoo strongly urges every sender to publish one. A p=none record changes nothing about delivery and gives you reports showing who is sending as your domain, so it is worth adding.

Why does my contact form email pass SPF but still go to spam?

Usually because the domain that passed SPF is your host's, not yours, so DMARC alignment fails, or because the From header uses the visitor's address. Send from your own domain, put the visitor in Reply-To, and make sure the sending service signs with DKIM for your domain.

Can I just add a second SPF record for my new email service?

No. RFC 7208 does not allow more than one SPF record per domain, and two records cause SPF to fail. Add the new service's include to your existing record instead, and keep the total DNS lookups at 10 or fewer.