Business email on your own domain: SPF, DKIM and DMARC made simple

An email from [email protected] earns more trust than one from [email protected]. But the address alone isn’t enough: if your domain’s DNS has no SPF, DKIM and DMARC records, your emails increasingly land in spam or never reach the recipient at all. We explain what each record does and how to set them up without an IT department.

Why your business should use email on its own domain

An address on your own domain shows straight away who is writing. The recipient doesn’t have to wonder whether [email protected] is really the company they spoke to on the phone. Your website, email and invoices share one name, so your business looks more trustworthy.

Control matters too. Mailboxes belong to the company, not to individual employees. When someone leaves, you can hand their mailbox to a colleague or forward their mail, and conversations with customers don’t disappear. If you switch email providers, your addresses stay the same, because the domain is yours.

Why emails end up in spam

Email was designed decades ago and doesn’t verify the sender by itself. Anyone can put any address in the “From” field, which makes it easy for scammers to pose as banks, couriers or even your company. Receiving servers fight this by checking the sender domain’s DNS records. If the records are missing or wrong, the message is treated as suspicious.

The major email providers have made these checks mandatory. Google and Yahoo announced their sender requirements back in February 2024, and since November 2025 Gmail has been rejecting non-compliant messages instead of just moving them to spam. Microsoft has applied similar requirements to Outlook.com and Hotmail recipients since May 2025.

Does this apply to small businesses? The strictest requirements apply to senders of more than 5,000 emails a day. But smaller senders without these records also land in spam more often, so every business should set them up.

Three records, three different questions

SPF, DKIM and DMARC aren’t programs you need to install. They are simple text (TXT) records in your domain’s DNS zone. Each one answers one question the receiving server asks:

Record	Question it answers	Think of it as
SPF	Is this server allowed to send email on behalf of your domain?	The guest list at the door
DKIM	Was the email really sent by you and left unchanged on the way?	A seal on the envelope
DMARC	What should happen if a check fails, and who should be told?	Instructions for security

They only work together: SPF and DKIM check the message, and DMARC says what to do with the result.

SPF: who can send on your behalf

An SPF record lists every server and service that sends email using your domain. That means not just your mailboxes, but also your newsletter tool, CRM, invoicing software or online store sending order confirmations.

yourcompany.com.   TXT   "v=spf1 mx include:_spf.google.com ~all"

v=spf1 – the start of the record, marking it as SPF.
mx – your domain’s mail servers are allowed to send.
include: – another provider’s servers are allowed to send, in this example Google Workspace.
~all – email from all other servers is treated as suspicious. The stricter -all means it is rejected.

Three rules

One domain, one SPF record. If there are two, neither works. Add new services to the existing record instead of creating a separate one.
No more than 10 DNS lookups. Every include:, a or mx counts as a lookup, and one include: can contain several more. Go over the limit and the SPF check fails.
Start with ~all. Once you’re sure every sender is included, you can switch to -all.

DKIM: a digital signature for every email

When sending a message, the mail server signs it with a private key. You publish the public key in DNS, and the recipient’s server uses it to check that the signature is genuine and the message wasn’t altered on the way.

default._domainkey.yourcompany.com.   TXT   "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC…"

The first part of the record (default in this example) is called the selector. It lets you have several keys at once, for example one for your mailboxes and another for your newsletter tool. Your email provider generates the key – you just copy it into DNS.

Tip. Choose a 2048-bit key. When copying it, make sure no spaces or line breaks slip in: a single wrong character means the signature can no longer be verified.

DMARC: what to do with fake emails

DMARC ties SPF and DKIM together. It checks that at least one of them passed and that the verified domain matches the one the recipient sees in the “From” field. Without this match, a scammer could send from their own domain with valid SPF while showing your address to the recipient.

_dmarc.yourcompany.com.   TXT   "v=DMARC1; p=none; rua=mailto:[email protected]"

The most important part of the record is p – the policy. rua sets the address for reports showing who sent email on behalf of your domain and from which servers.

Policy	What happens to a fake email	When to use it
p=none	Nothing – you just receive reports	First 2–4 weeks
p=quarantine	It goes to spam	When reports show only your own senders
p=reject	It is rejected and never reaches the recipient	The end goal

Don’t jump straight to p=reject. If you forgot to include, say, your invoicing software, its emails will simply stop reaching customers. Start in monitoring mode, review the reports and tighten the policy step by step.

Check your domain

Enter your domain to see which records are already in place and what needs fixing.

Domain or email address

The check runs in your browser using the public Google Public DNS service. If you’ve just changed your records, it may take a few hours for the changes to show.

Most common mistakes

Two SPF records. When a newsletter tool is connected, a second record is created instead of updating the existing one. Then SPF stops working altogether.
Forgotten senders. Mailboxes are set up, but online store order emails or newsletters go out through another service that isn’t in SPF and has no DKIM.
Going straight to p=reject. Some legitimate emails vanish and nobody understands why.
Nobody reads the reports. DMARC reports arrive as XML. Give them a separate mailbox or use a report analysis tool.
Sending from a VPS without reverse DNS. If you send email from your own server, its IP address needs a PTR record pointing to your mail server’s name. Without it, some providers reject your messages.

Where to start

Register a domain. Until 8 November, the first year is free with an E-COMMERCE, PLUS or VPS plan ordered for 12, 24 or 36 months.
Create mailboxes. They are already included in web hosting plans. On a VPS, you can install your own mail server or use an external email provider.
Add SPF and DKIM records using the values provided by your email provider.
Publish DMARC with p=none and a report address.
Check your domain with the form above, and after a few weeks of reviewing the reports, tighten the policy.

If you have questions about DNS records, contact the Redfox Cloud support team.

Interested? Here’s more news and insights

All news