SPF, DKIM and DMARC for support email
SPF, DKIM and DMARC are three DNS records that prove your support email really comes from you. Set them up correctly and your replies reach the inbox; leave them missing and they land in spam. This guide explains what each one does, how to set the three up, and why support email is so often the worst offender.
Email-first and UK-first. Solves checks these records as part of guided mailbox setup.
The short answer
What are SPF, DKIM and DMARC?
SPF, DKIM and DMARC are three standards that let a receiving mail server check that an email genuinely came from your domain and was not forged or tampered with. SPF lists the servers allowed to send for you, DKIM signs each message so it cannot be quietly altered, and DMARC ties the two together, sets the policy for failures, and gives you reports. Together they are the difference between a support reply that lands in the inbox and one that lands in spam.
You do not need to be a mail expert to get them right. Each is a single record published in your domain DNS, and your sending provider gives you most of the values. The goal of this guide is to explain each record in plain English, show the order to set them up in, and help you avoid the mistakes that send support mail to the junk folder.
The approach here lines up with the kind of monitoring the UK National Cyber Security Centre encourages through its Mail Check service: publish the records, start by watching reports rather than blocking, then tighten the policy once everything passes. You can use Mail Check or your provider dashboard to keep an eye on the results over time.
The three records
What each record actually does
SPF, DKIM and DMARC answer three different questions about the same message.
SPF: who can send
A TXT record listing the servers and providers allowed to send mail for your domain. The receiving server checks whether the sending IP is on your list. It answers: did this come from a server I authorised?
DKIM: was it tampered with
A cryptographic signature added to each outgoing message, verified against a public key you publish in DNS. It proves the body and key headers were not changed in transit and that your domain signed it.
DMARC: what to do on failure
A policy record that checks SPF or DKIM aligns with your visible from address, tells receivers whether to allow, quarantine or reject failures, and asks them to send you reports so you can see what is happening.
How they fit together
How SPF, DKIM and DMARC work as a set
Think of a customer opening a reply from your support team. Behind the scenes, their mail server runs three quick checks before it decides where to put the message. SPF confirms the sending server was one you authorised. DKIM confirms the message was not altered and was signed by your domain. DMARC then checks that whichever of those passed lines up with the domain shown in the from address, and applies your chosen policy if neither does.
Why DMARC needs alignment, not just a pass
It is possible for SPF or DKIM to pass for some other domain while your customer sees yours in the from line. DMARC closes that gap by requiring alignment: the passing record must match the visible domain. This is what stops a spammer from borrowing a legitimate server to forge your brand, and it is why a DMARC record on its own, without working SPF or DKIM beneath it, achieves very little.
You do not need both SPF and DKIM to pass
DMARC passes if either SPF or DKIM passes and aligns, so a single working record is technically enough. In real support email you should still configure both. DKIM survives forwarding far better than SPF, which often breaks when mail is forwarded from a shared inbox through several hops, so having both gives you a safety net rather than a single point of failure.
Setup
How to set up SPF, DKIM and DMARC
Publish your SPF record
Add one TXT record at your root domain that includes your sending provider, for example a record that includes Postmark, and ends in a soft-fail policy such as tilde-all while you test. Keep it to a single SPF record: more than one is invalid and will break authentication.
Add DKIM signing
Your provider gives you a public key to publish, usually as a CNAME or TXT record, and signs every outbound message with the matching private key. Once the key is live in DNS, outgoing support mail carries a signature that receiving servers can verify.
Publish a DMARC policy
Add a TXT record at the name beginning with an underscore-dmarc prefix for your domain. Start with a monitoring policy of none and an rua address so you receive reports, rather than blocking mail before you know it is configured correctly.
Monitor, then tighten
Watch the DMARC reports, or use a service such as NCSC Mail Check, until SPF and DKIM consistently pass and align. Only then move the DMARC policy from none to quarantine and eventually reject, so you block forgeries without losing genuine support replies.
The record values
What the records look like
A quick reference for the three records, in the order you publish them. Your sending provider supplies the exact values; these show the shape so the dashboard instructions make sense.
| SPF (TXT, root domain) | A single TXT record that includes your provider and ends in a policy such as tilde-all. One SPF record only, never two. |
|---|---|
| DKIM (CNAME or TXT) | A provider-issued public key, published at the selector host they give you, so receivers can verify the signature on each message. |
| DMARC (TXT, _dmarc host) | A policy record starting at none for monitoring, with an rua reporting address, tightened to quarantine then reject once checks pass. |
You make these changes wherever your domain DNS is managed, which is usually your domain registrar or DNS host, not your email provider. After publishing, allow time for the changes to propagate, send a test message, and check the headers or your provider dashboard to confirm SPF, DKIM and DMARC all pass before relying on the domain for live support.
The spam problem
Why support email goes to spam without these records
Support email is unusually prone to spam filtering, and authentication is almost always the reason. A shared inbox like support@ is often forwarded through several systems before a reply goes out, and every hop is a chance for SPF to break or a signature to be stripped. When a message arrives looking like it is from your domain but failing its checks, a cautious receiving server has little choice but to treat it as suspicious.
The common failure patterns
- No SPF or DKIM at all, so the receiving server cannot confirm the mail is yours.
- A DMARC record published with no working SPF or DKIM beneath it, which fails alignment.
- Two SPF records on one domain, which is invalid and causes SPF to fail outright.
- Forwarding from a shared inbox that breaks SPF and strips DKIM before the reply is sent.
- A poor sending reputation built up while mail was going out unauthenticated.
Why fixing the records is the biggest single win
Wording, links and reputation all matter, but none of them help if a message fails authentication on arrival. Publishing correct SPF, DKIM and DMARC is usually the single largest improvement you can make to support deliverability, because it moves your mail from unverified to trusted in the eyes of every major receiver. Get the three right before you scale up volume, not after complaints start.
Solves gates live sending until the checks pass
When you connect a support mailbox in Solves, setup is forwarding-first and live sending stays blocked until the mailbox is verified or a founder override is recorded. That keeps a half-configured domain from quietly sending unauthenticated mail, which is exactly the situation that lands support replies in spam.
FAQ
Common questions about SPF, DKIM and DMARC
What is SPF, DKIM and DMARC?
They are three DNS records that prove your support email really comes from you. SPF (Sender Policy Framework) lists the servers allowed to send for your domain. DKIM (DomainKeys Identified Mail) adds a cryptographic signature that shows a message was not tampered with in transit. DMARC (Domain-based Message Authentication, Reporting and Conformance) ties the two together, tells receiving mail servers what to do when a message fails, and asks them to send you reports. Set up correctly, the three together make a support reply far more likely to reach the inbox rather than the spam folder.
How do I authenticate my email via SPF, DKIM and DMARC?
You publish three records in your domain DNS. For SPF, add a single TXT record that includes your sending provider (for example, Postmark) and ends in a policy such as ~all. For DKIM, your provider gives you a public key to publish, usually as a CNAME or TXT record, and signs outbound mail with the matching private key. For DMARC, add a TXT record at _dmarc.yourdomain.com that sets a policy (start at p=none to monitor) and an rua address to receive reports. Change DNS at your domain registrar or DNS host, wait for it to propagate, then send a test and check the headers. Solves walks you through the exact values for your mailbox during setup.
Does DMARC need both SPF and DKIM?
No. DMARC passes if either SPF or DKIM passes and aligns with the domain in the visible from address, so you do not strictly need both. In practice you should set up both anyway. DKIM survives forwarding and aligns reliably, SPF can break when mail is forwarded, and having both gives you redundancy so a single failure does not send your support reply to spam. Use DMARC to monitor first, then tighten the policy once both are passing.
What is the difference between SPF and DKIM?
SPF checks the sending server: it asks whether the IP address that delivered the message is on the list you published for your domain. DKIM checks the message: it verifies a signature added when the mail was sent, proving the body and key headers were not changed and that the signing domain authorised it. SPF is about where the mail came from; DKIM is about whether the mail is intact and signed. DMARC then checks that whichever one passed lines up with the domain your customer actually sees.
How long does it take for SPF, DKIM and DMARC to work?
The records themselves are small and quick to add, but DNS changes take time to spread across the internet. Many updates are visible within minutes; some can take up to a few hours, and occasionally up to 24 to 48 hours depending on your DNS host and its time-to-live settings. After you publish, send a test message and check the headers or your provider dashboard before going live. Solves keeps live sending for a mailbox gated until its checks pass, so a half-configured domain cannot quietly send unauthenticated mail.
Why is my support email going to spam?
The most common cause is missing or misconfigured authentication: no SPF, no DKIM, or a DMARC record that does not align. Receiving servers treat unauthenticated mail from a real-looking domain as suspicious, especially from a shared inbox forwarded through several hops. Other factors include a poor sending reputation, spammy wording, broken forwarding that strips signatures, and no DMARC policy at all. Fixing the three records is usually the single biggest improvement, which is why getting them right matters before you scale up support volume.
Get support email that lands in the inbox
Solves checks SPF, DKIM and DMARC as part of guided mailbox setup, with copyable DNS steps and live sending gated until they pass.