E-mail was designed at a time when nobody lied about who they were. Today anyone can write a message pretending to come from your domain — and these three records are what prove yours is genuine.
| Record |
What it proves |
| SPF |
The list of servers allowed to send on behalf of your domain. The receiver checks the message came from one of them. |
| DKIM |
A digital signature on every message. It proves the message really left your system and nobody altered it on the way. |
| DMARC |
The instruction for what to do when a message fails the other two: let it through, mark it as spam, or reject it. |
Why this actually matters to you
Without these records, Gmail and Outlook.com have two choices — take a risk, or put it in spam. In doubt, they choose spam. That explains the overwhelming majority of "they say they never got it" cases. It is also what stops someone sending fake invoices in your company's name.
How it works with us
| 1 |
If the domain uses our nameservers , SPF and DKIM are created automatically when the account is opened. You need do nothing.
|
|
| 2 |
If the DNS is at another provider, the records exist on our side but have to be copied there. This is the silent cause of a lot of mail in spam folders — ask us for the values and we will send them.
|
|
| 3 |
DMARC is not automatic, and rightly so: a strict policy before everything else is in place will reject your own e-mail. You start by observing, and tighten later.
|
|
If you send e-mail from other places
An invoicing system, an online shop, a campaign platform or the website contact form also send in your domain's name. Each of them has to be included in the SPF, or the messages leaving through them fail the check.
|
There can be only one SPF record. When adding a new service you merge it into the existing SPF — you do not create a second one. Two SPF records cancel each other out, and that is worse than having none.
|