SPF, DKIM and DMARC are three records that let the receiving server check whether an email was really sent from your domain. When the email protocol was designed decades ago, it had no mechanism to verify the sender's address, much like being able to write any return address you like on an envelope. Fraudsters take advantage of this: they send your customers or your accounting team a "our bank account has changed" email using your domain. In this post we explain what the three records do, in what order to set them up and the common mistakes.
Three records, three separate questions
| Record | The question it answers | In plain terms |
|---|---|---|
| SPF | Is this server allowed to send mail on behalf of this domain? | A list of the servers allowed to send mail on behalf of your domain |
| DKIM | Was this email altered in transit, and did it really come from that domain? | A digital signature added to every outgoing email; the recipient verifies it with the public key in DNS |
| DMARC | If SPF and DKIM fail, what should happen, and should reports be sent to me? | The domain owner's instructions to recipients and a feedback channel |
SPF and DKIM are not enough on their own, because neither directly protects the "From" address the recipient sees. DMARC matches the results of these two checks against the visible sender address (this is called alignment) and decides what happens to emails that fail.
Why it's no longer optional
Large email providers are increasingly making these records mandatory. Google and Yahoo tightened their sender rules starting in February 2024: according to Google's sender guidelines, all senders are expected to have at least SPF or DKIM, and those sending high volumes to Gmail addresses are expected to have SPF, DKIM and DMARC all in place. Proposal and invoice emails from companies missing these records are landing in spam folders more and more often.
The security side matters even more. Fake invoice and bank account change fraud leads directly to financial loss. A phishing email sent in your company's name can lead to your customer's personal data being stolen, which raises questions of responsibility in terms of both reputation and KVKK (Türkiye's Personal Data Protection Law).
Step-by-step setup
- List every sending source. Your business email server, website form notifications, the e-invoice system, the newsletter tool, the CRM, the support software. Every source you forget means its emails will be rejected once DMARC is tightened.
- Write one clean SPF record. A domain should have only one SPF record. All authorized sources are added to that single record. Remember that SPF has a DNS lookup limit; if too many services are added, the record can become invalid.
- Turn on DKIM for every sending source. Each service provides its own DKIM key, which is added to DNS. Keys should be long enough (the current recommendation is at least 2048 bits).
- Start DMARC in monitoring mode. In the first phase the policy is "none"; no email is blocked, only reports are collected. The reports show who is sending email on behalf of your domain.
- Read the reports and fix the missing sources. A forgotten newsletter tool or printer usually turns up at this stage.
- Tighten gradually. First "quarantine" (send to the spam folder), then after a few trouble-free weeks "reject." The goal is for fake emails never to reach the recipient at all.
Common mistakes
- Two separate SPF records. Both are then treated as invalid.
- Leaving the end of the SPF record too loose. An expression that allows any server makes the record meaningless.
- Leaving DMARC at "none" forever. Monitoring mode offers no protection; it only produces reports. Many domains stay at this stage for years.
- Forgetting unused domains. Your secondary domains that don't send email can be spoofed too. For them, publish an SPF record saying "no server is authorized" and a DMARC record with a "reject" policy.
- Skipping website forms. Form notifications sent directly from the web server go out without a DKIM signature and end up in spam.
Checklist
- All sending sources are listed
- There is a single SPF record covering all sources
- DKIM signing is enabled on every source
- A DMARC record exists and reports are read regularly
- The policy has moved from monitoring to quarantine or reject
- Secondary domains that don't send email are protected too
- The accounting and sales teams know to confirm bank account change emails by phone
The last item isn't technical, but it matters as much as the others: no record can stop an email sent from a real account that has been compromised. For account security, see our post on password policy and 2FA.
How we do it at Globya
In business email and website setups, we configure SPF, DKIM and DMARC from the start, and we send the site's form notifications signed as well. On an existing domain, we first take an inventory of sending sources, turn on DMARC in monitoring mode, read the reports together and move step by step to the reject stage. In line with our KVKK compliance approach, these requirements carry no extra charge.
Frequently asked questions
If we add these records, will our emails never land in spam?
It isn't a guarantee, but it clearly improves deliverability. Content, sending volume and how recipients react also affect spam decisions.
Can we start DMARC directly with "reject"?
We don't recommend it. If there is a forgotten sending source (for example e-invoice notifications), those emails will be rejected too. Seeing the reports in monitoring mode first is the safe route.
How do you read DMARC reports?
The reports are XML files written for machines. A reporting tool or a team that does this work turns them into readable summaries; the main thing to look for is sending sources you don't recognize.
Can you check the status of our domain?
Yes. Reach us at +90 850 432 55 13 or through the contact page; we'll review your domain's SPF, DKIM and DMARC status and send you our recommendations in writing.
The Globya assistant is online 24/7; it answers right away and passes your question to the team if needed.