Insights · globalhr.ro
Business email on your domain: SPF, DKIM and DMARC explained
In short: SPF lists which servers may send email for your domain, DKIM adds a cryptographic signature that proves a message was not altered, and DMARC tells receiving servers what to do when a message fails those checks and sends you reports. Together they make your domain harder to impersonate and help legitimate mail reach inboxes.
SPF, DKIM and DMARC are three DNS records that let receiving mail servers check whether an email that claims to come from your domain is genuine. They are published in your domain's DNS, cost nothing to add, and are now expected by the largest mailbox providers. If your business sends invoices, quotes or document requests by email, they are among the most useful security settings you can have.
Why your domain needs them
The basic email protocol lets anyone type any address into the "From" field. Criminals use that to send fake invoices or payment-change requests that appear to come from real businesses. Authentication records give receivers a way to tell genuine messages from forgeries. Since 2024, Google and Yahoo have required all senders to authenticate their mail, with stricter rules, including a DMARC record, for anyone sending large volumes to their users. Even if you send modest volumes, missing records make it more likely that your messages are filtered or rejected.
SPF: who is allowed to send
Sender Policy Framework (SPF, defined in RFC 7208) is a TXT record that lists the servers and services permitted to send mail for your domain. A receiving server looks up the record and checks whether the sending server is on the list.
A typical record looks like this: v=spf1 include:mail.example-provider.com include:invoicing.example.com ~all. Each include points to a provider's list of servers. The ending matters: ~all asks receivers to treat other senders as suspicious (soft fail), while -all asks them to reject (hard fail).
- Publish only one SPF record per domain; two records cause failures.
- SPF allows a maximum of 10 DNS lookups. Every include counts, so trim services you no longer use.
- SPF checks the technical sender address, not the visible From address, which is why DMARC is needed on top.
DKIM: proof the message was not changed
DomainKeys Identified Mail (DKIM, RFC 6376) adds a digital signature to each outgoing message. Your mail server signs with a private key; the matching public key is published in DNS under a name such as selector1._domainkey.yourdomain.com. The receiver uses the public key to verify that the signature is valid and that the signed parts of the message were not altered on the way.
Each service that sends mail for you, such as your mailbox provider, newsletter tool or invoicing software, should sign with your domain using its own selector. DKIM survives forwarding better than SPF, which makes it the more dependable of the two.
DMARC: the policy and the reports
Domain-based Message Authentication, Reporting and Conformance (DMARC, RFC 7489) ties the other two together. It is a TXT record at _dmarc.yourdomain.com that does three things:
- Requires alignment: the domain that passes SPF or DKIM must match the domain in the visible From address.
- States a policy for messages that fail: p=none (monitor only), p=quarantine (treat as spam) or p=reject (refuse).
- Asks receivers to send aggregate reports to an address you choose, using the rua tag, so you can see who is sending mail as your domain.
A cautious starting record is: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com. Once the reports show that all your legitimate services pass, you move to quarantine and then reject.
How the three work together
| Record | Answers the question | Where it lives | Common mistake |
|---|---|---|---|
| SPF | Is this server allowed to send for the domain? | TXT on the domain | Two SPF records, or more than 10 lookups |
| DKIM | Was this message signed by the domain and left unaltered? | TXT at selector._domainkey | A sending service not set up to sign |
| DMARC | Does the From domain align, and what happens on failure? | TXT at _dmarc | Jumping straight to reject before checking reports |
A message passes DMARC if it passes either SPF or DKIM with alignment. That is why getting DKIM right on every service is so important.
Setup checklist
- List every service that sends email using your domain: mailboxes, website forms, CRM, newsletters, invoicing, scheduling and support tools.
- Build one SPF record that includes the services that need it, and count the lookups.
- Turn on DKIM signing in each service and publish its public key in DNS.
- Publish a DMARC record with p=none and a reporting address.
- Read the reports for a few weeks and fix any legitimate source that fails.
- Move to p=quarantine, then to p=reject when you are confident.
- Review the records whenever you add or drop an email-sending tool.
Limits and trade-offs
These records protect your domain from being impersonated, but they do not stop look-alike domains, such as one with a swapped letter, and they do not guarantee inbox placement; content and sending behavior still count. A strict reject policy will also block a legitimate tool that you forgot to configure, so the monitoring phase is not optional. DMARC reports are raw XML, so most businesses use a report-reading tool or ask their provider to interpret them.
If you prefer not to manage DNS yourself, the Professional package at globalhr.ro includes business email on your domain with SPF, DKIM and DMARC configured, alongside your website. Questions about moving your current email are welcome through the request form.
Questions and answers
Do I need all three records?
Yes. SPF and DKIM provide the checks, and DMARC links them to the visible From address and tells receivers what to do on failure. Major providers expect all three from businesses that send regularly.
Will DMARC break my email?
Not with p=none, which only monitors. Problems arise when you move to quarantine or reject before confirming that every legitimate sending service passes. Read the reports first, then tighten gradually.
How do I check my current records?
Look up your domain's TXT records with any DNS lookup tool, or check the authentication results in the headers of a message you sent to yourself at a large mailbox provider.