Email going to your customer’s spam: how to put SPF, DKIM and DMARC in order

Email going to spam: what can cause it

If a customer says your email goes to spam, look at the sender first and only then at the text. A receiving mail server, such as Gmail’s or Outlook’s, checks whether a message really comes from the domain shown on it. If it cannot confirm that, the server decides for itself what to do: reject the message, put it in the junk email folder or deliver it anyway.

These are the causes you can check yourself:

• Your domain does not name all senders. Ordinary email from your mailbox, invoices from an accounting package, reports from your service software: all with @yourcompany.be as the sender, while your SPF record knows only one of them.
• There is no DKIM signature, or it is in the name of the service’s domain instead of yours.
• There is no DMARC record. Then you also get no reports on what goes wrong.
• There are two SPF records, because a new package asked you to “add an SPF record”.
• You send from a free address. For gmail.com or hotmail.com you cannot set up SPF or DKIM, because that domain is not yours.
• Recipients mark your email as spam. At Gmail, that counts towards your domain’s spam rate.

You notice the cost later: an invoice nobody read, an appointment reminder that sat in spam, and every time a phone call to send everything again.

SPF, DKIM and DMARC in plain words

All three are records in the DNS of your domain, the list your domain provider keeps. They tell a recipient what to expect from email that has your domain as the sender.

DMARC also checks whether the domain for which SPF or DKIM passes is the same as the domain in the From address your customer sees. If an invoicing service passes SPF with its own domain, that does not count for your DMARC; the domain has to be yours.

In which order do you set up SPF, DKIM and DMARC?

1. Make a list of everything that sends email with your domain. Your mailbox, the accounting package, your service software, the newsletter, the contact form on the website. Ask each service which SPF line and which DKIM key it needs.
2. Put SPF in one record. According to Microsoft, only one SPF record per domain is allowed (in Dutch), and the check fails if it requires more than ten DNS lookups. For a service you do not manage yourself, such as a newsletter, Microsoft recommends a subdomain, for example news.yourcompany.be.
3. Turn on DKIM at every service. The service creates the key, you add the record at your domain provider, then you turn on signing. According to Google (in Dutch), it can take up to 48 hours before verification works. For Microsoft 365, the procedure is in Microsoft’s guide (in Dutch).
4. Then publish DMARC, set to “none”. Google asks you (in Dutch) to turn on SPF and/or DKIM first, wait 48 hours and start with the policy none, for example “v=DMARC1; p=none; rua=mailto:[email protected]”. The reports arrive at the address after rua; Google recommends a separate mailbox for them.
5. Read the reports, then tighten. If a source that belongs to you fails, add it or give it a subdomain. Once your own sources pass, Google says you move to quarantine or reject over time.

You add the records at your domain provider, or you have your IT partner add them, using the list from step 1.

How do you check whether SPF, DKIM and DMARC work?

Send a test email to a Gmail address and an Outlook.com address that you manage yourself, and open the full header: in Gmail via More and Show original (Google’s help, in Dutch), in Outlook via the internet message headers (in Dutch). Look for the line Authentication-Results.

The meaning of each value is set out in Microsoft’s explanation of message headers (in Dutch).

What do Gmail and Outlook ask of senders?

Gmail, in its guidelines for email senders (in Dutch), asks every sender to personal Gmail accounts for, among other things, SPF or DKIM, valid DNS records for the sending domain or IP address, a TLS connection and a spam rate below 0.3% in Postmaster Tools. Anyone who sends 5,000 or more messages a day needs SPF and DKIM, a DMARC record (the policy none is enough), a From domain that matches the SPF or DKIM domain and, for marketing messages, one-click unsubscribe.

Outlook.com asks anyone who sends 5,000 or more messages with the same domain to Microsoft’s consumer services for: SPF and DKIM that pass, a DMARC record (at least p=none) and SPF or DKIM that matches the From domain. Otherwise, Outlook.com rejects the message (in Dutch) with the error 550 5.7.515.

With SPF, DKIM and DMARC in order, you meet the authentication that both providers ask of bulk senders, even if you stay far below that threshold. How a business customer’s mail server filters is up to that customer.

Good habits for invoices, reports and reminders

• One domain, your own, never a free address.
• A reply address that someone reads, so that a question about an invoice reaches accounting.
• A subject the customer recognises, such as “Invoice 2026-0412 from [company name]”.
• A few sentences with the attachment: who you are, what it is about and who the customer can call.
• No shortened links. The customer must see where a link goes.
• A test email after every new service that sends email, as soon as it is in SPF and DKIM.

An example: a heat pump installer’s reports in spam

A company that installs and maintains heat pumps sends email from its office mailbox, its accounting package and its service software, each time with the same domain. Private customers with a Gmail address find the reports in their spam. The managing director sends a test report to their own Gmail address and reads spf=permerror and dkim=none in the header. There is no DMARC record.

Their IT partner finds two SPF records: the old one from the hosting and a new one for the accounting package. The IT partner merges them into one record with the three services and turns on DKIM where it was missing. Two days later, the IT partner publishes DMARC set to none, with the reports going to a separate mailbox. After a week, those reports still show one source that fails, the newsletter service, which gets its own subdomain. The next test email shows spf=pass, dkim=pass and dmarc=pass.

How it works in Digitalnatie Service Suite

Service Suite sends, among other things, intervention reports, invoices, invitations and password links by email. To have them leave from your company’s address, the administrator connects a domain and an outgoing server in the email configuration.

• Domain and server: the administrator adds your domain, then connects the outgoing mail server (SMTP) of your email provider: server, port, security (for example STARTTLS on port 587), username and password. Your company’s email address appears on the documents and serves as the reply address.
• Testing: the test email goes to your own address by the real route: server, sender and domain. Read its header as explained above. If the email still leaves under a domain of the platform, the screen shows a yellow warning.
• Invoices and reports: sending a posted invoice and sending the report of a completed intervention both send the PDF by email, from the connected email account. For a report, the confirmation shows the recipient, the sender and that the mail server accepted the message. More about invoicing.
• Reminders: no email goes to a customer as long as your organisation’s email account is not connected. For your own automation rules, sending emails to customers must also be allowed, a setting you ask Digitalnatie for.

Good to know:

• The DNS records, such as MX, SPF and DKIM, are set up at your domain provider, not in the application. Which values you need depends on the outgoing server you connect: ask your email provider or IT partner for them.
• As soon as the email is connected, the sends are real. Without connected email, you download the document and deliver it yourself.
• The confirmation that the mail server accepted the message means that the server took it. Which folder it lands in at the customer’s is not shown.

What to do when an invoice remains unpaid is explained in sending a payment reminder, and what belongs in the report in the intervention report to the customer. The email that customers send you is covered in a shared inbox for service requests.

Frequently asked questions

Why does my email end up in spam at customers?

A receiving server checks whether the message really comes from your domain. If the sending service is not in your SPF record, a DKIM signature is missing or your domain has no DMARC record, it cannot check that and decides for itself what to do with the message. At Gmail, how often recipients mark your email as spam also counts.

What is the difference between SPF, DKIM and DMARC?

SPF says which servers may send email with your domain as the sender. DKIM puts a signature on every message, which the recipient checks with a key in your DNS. DMARC says what a recipient should do with email that fails SPF and DKIM for your domain, and to which address it sends reports.

Should I set DMARC to reject straight away?

No. Google recommends starting with the policy none, reading the reports and only moving to quarantine or reject over time. That way you first see which services send email with your domain, before their messages are rejected.

Does Service Suite set up SPF, DKIM or DMARC for me?

No. You set up the DNS records at your domain provider. In Service Suite, the administrator connects your domain and your email provider’s outgoing server, and sends a test email by the real route. The header of that test email shows whether the checks pass.