SPF, DKIM and DMARC are three TXT records in a domain’s DNS. Their job is simple: to confirm to recipients’ servers that a message really was sent by your company. Without them, emails land in spam more often and a scammer can impersonate a company address more easily.
Did an invoice for a client end up in the junk folder? Are your business partners getting strange messages “from you”? The cause usually lies right here. Below I explain what each of these records does, in what order to set them up and how to check that they work. It is just as worthwhile to look after how your company appears outside the inbox, for example by setting up the social media link previews.
Table of contents
Why do company emails end up in spam even though you send them correctly?
Because the recipient’s server does not trust a message whose sender cannot be authenticated. So it moves the message to spam or simply rejects it. The whole verification relies on DNS records, which are public entries in the domain’s zone (any server in the world can read them). According to Gmail’s requirements for senders, Google recommends setting up SPF, DKIM and DMARC, and unauthenticated messages may be marked as spam or rejected with a 5.7.26 error.
And then there is the other side of the coin: impersonation of the company domain. A domain without authentication is an open door. Anyone can send an email with your address in the sender field, for example asking for a transfer to a “new account”. The client sees a familiar address and has no reason to suspect anything. And it is the company’s reputation that takes the hit.
SPF, DKIM and DMARC: how they differ and how they work together
In short: SPF says which servers are allowed to send mail from the domain. DKIM signs every message with a key. DMARC tells the recipient what to do with an email that failed those tests. Each mechanism patches a different hole, so they only make sense as a set:
- SPF (Sender Policy Framework) is a list of servers and services authorized to send on behalf of the domain.
- DKIM (DomainKeys Identified Mail) adds a digital signature to the message, which the recipient checks with the public key published in DNS.
- DMARC combines both results, defines the policy for suspicious emails and sends reports to the domain owner.
There is one more catch that a lot of people forget about. Alignment. The domain visible in the From header must match the domain checked by SPF or by DKIM. If it does not match, DMARC will treat the message as unauthenticated, even with a valid signature. A bit sneaky, but that is how it works.
How to set up an SPF record for a domain
An SPF record for a domain is a single TXT entry starting with v=spf1. In it you list all the services that send mail on behalf of the company. And this is where the real work begins, because before you write anything you need to take an inventory of your senders: the mail server, the online store, the CRM, the newsletter system, the invoicing software. Each of these tools gives its own include entry in its documentation, which you add to the record.
The most common slip-up? Two separate SPF records instead of one. The result is that both become invalid. The second classic is a missed external sender, and as Google’s documentation on email authentication points out, messages from providers not included in the record end up in spam more often. If you keep your mail with a provider that manages the DNS zone itself, as with the email hosting for business service, the basic entry is often already in place. Then all you need to do is extend it.
Enabling DKIM: a key in the mail panel and a record in DNS
You enable DKIM in the panel of your mail service. The service generates a key pair, and you publish the public key in DNS as a TXT record under a so-called selector (it is simply a name that tells the keys of different services apart). The whole process looks like this:
- Generate a key in the mail panel (Google Workspace, Microsoft 365 or your hosting panel).
- Add a TXT record in the DNS zone with the given selector name and key value.
- Turn on message signing in the mail panel.
- Send a test email and check the verification result.
Key length does matter. Google’s guidelines for senders require at least 1024 bits when sending to personal Gmail accounts, and for security reasons they recommend 2048 bits if the provider supports it. In my opinion there is no point overthinking it: if you can, go with 2048. Oh, and one more thing. Every external sender needs its own DKIM key in DNS, for example a newsletter tool, without which it is hard to run effective email marketing in a company.
DMARC record: step-by-step configuration, from p=none to p=reject
You publish the DMARC record as a TXT entry under the name _dmarc.yourdomain.pl. Always start with the none policy, which only collects reports and blocks nothing. A sample entry: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.pl. The v tag is the protocol version, p sets the policy and rua points to the mailbox for aggregate reports.
You tighten the policy slowly. First none, then quarantine (suspicious emails go to spam), and finally reject (the server rejects them). No rush. The next step only makes sense once the reports show that all legitimate mail passes verification. And along the way, the same reports show who is sending messages on behalf of the domain at all. Scammers included.
How to check that SPF, DKIM and DMARC work correctly
The simplest way: send a message to a Gmail mailbox, open it and choose Show original from the menu. SPF, DKIM and DMARC should each show a PASS status. Is one of them showing FAIL? Check, in order, for typos in the record, a missing sender in SPF and whether the domain in the From field matches the signing domain. In practice it is usually one of these three.
Do you have a lot of services sending mail, or nobody who will read the reports regularly? Then it is honestly more sensible to hand the topic over to specialists, for example as part of the outsourced IT support service. It is worse if the reports show sending from your server that nobody in the company ordered. That is a sign that the website or a mailbox may have been taken over and you need to act fast. In that case, a guide on what to do after a break-in will come in handy.
Where to start? List all the services that send mail from the domain and build one correct SPF record from that. Then DKIM for every sender. Set DMARC to none and simply collect reports for a few weeks. Only with that knowledge will you tighten the policy without the risk of blocking your own invoices. Properly configured SPF, DKIM and DMARC mean better deliverability and protection of your brand against impersonation. All in one go.
Frequently asked questions
Does a small company that does not send newsletters need DMARC?
Yes. DMARC protects first and foremost against domain impersonation, and every company with its own address is exposed to that, no matter how many emails it sends. Large mail providers, including Google, recommend it to all senders.
Can I have two SPF records in one domain?
No. Two SPF records invalidate the verification. You combine all services in a single TXT entry using successive include mechanisms.
Does the p=none policy do anything at all?
It blocks nothing, that is true. But it delivers reports that show who is sending mail on behalf of the domain. Without that data you cannot safely move to quarantine or reject.
