How to set up SPF, DKIM and DMARC correctly

Applies to: All plans. If you ordered your Microsoft 365 or Google Workspace seats through us, we set SPF, DKIM and DMARC up for you, so you can skip the steps below — whatever your hosting plan.

Before you start: You need access to your client area (my.maxinodes.com), your domain pointed at our nameservers (ns1.maxinodes.com and ns2.maxinodes.com), and, for Microsoft 365 or Google Workspace, your email already set up there. The exact record values are tenant-specific and always come from the Microsoft 365 admin centre or the Google Workspace admin console — never copy values from another domain.

SPF, DKIM and DMARC are three small DNS records that prove your email is genuine. Together they stop spammers from forging your address and help keep your messages out of spam folders. You add all three in your client area, then start DMARC gently at p=none so nothing breaks.

What each record does

SPF (a TXT record) lists which servers are allowed to send email for your domain. Receivers treat mail from anywhere else as suspicious.
DKIM (CNAME records for Microsoft 365, or a TXT record for Google Workspace) adds a tamper-proof signature to every message, so receivers can confirm it was not altered in transit.
DMARC (a TXT record at _dmarc) ties SPF and DKIM together and tells receivers what to do when a message fails — do nothing, send to spam, or reject. You also use it to receive reports about who is sending as you.

Using the mailboxes included in your plan?

If your domain uses our nameservers, the records for the mailboxes included in your hosting plan are added to its zone for you when the hosting zone is created, so you can skip Steps 1 and 2:

Record	Type	Name (host)	Value
SPF	TXT	`@`	`v=spf1 include:_spf.maxinodes.com ~all`
DKIM	TXT	`default._domainkey`	The key cPanel created for your domain
DMARC	TXT	`_dmarc`	`v=DMARC1; p=none`
Relay authorisation	TXT	`_mailchannels`	`v=mc1 auth=maxinodes`

DKIM signing starts once cPanel's daily check has confirmed the published key, so the first messages from a new account can go out without a DKIM signature. The DNS manager in your client area always shows the live values; if any of these records is missing, ask us to add it. If your DNS is hosted elsewhere, add the records there yourself: ask us for your domain's values (the DKIM key is made for your domain), and see The DNS records your email needs (MX, SPF, DKIM, DMARC). Steps 3 and 4 below still apply: your zone already has a DMARC record at p=none, so edit it to add a report address rather than adding a second one.

Step 1 — Get your values from Microsoft 365 or Google Workspace

For Microsoft 365, sign in to the Microsoft 365 admin centre and open the area for your domain and DKIM settings. Note the SPF text, the two DKIM CNAME records (selector1 and selector2), and the autodiscover record.
For Google Workspace, sign in to the Google Workspace admin console and follow the option to authenticate email. Generate the DKIM key and note the SPF text and the DKIM record.

Result: You have the exact records to add. For Microsoft 365 and Google Workspace, treat the provider's console as the source of truth.

Step 2 — Add SPF and DKIM in your client area

Go to client area -> Domains -> My Domains and open the DNS management for your domain (see the related article below for the full walkthrough).
Add the SPF record as a TXT record at the root of your domain:
- Microsoft 365: v=spf1 include:spf.protection.outlook.com -all
- Google Workspace: v=spf1 include:_spf.google.com ~all
Add the DKIM records:
- Microsoft 365: add the two DKIM CNAME records exactly as shown in the admin centre (selector1 and selector2).
- Google Workspace: add the DKIM TXT record at google._domainkey with the value from the admin console.
Save your changes.
Microsoft 365 only — turn on signing with your own domain. Publishing the two CNAMEs is not the same as enabling DKIM. Go back to the Microsoft 365 admin centre and enable DKIM signing for your own domain. Until you do, Exchange Online keeps signing with yourtenant.onmicrosoft.com: the signature verifies, but it does not align with your From: domain, so DMARC then passes on SPF alone.

Result: Your domain authorises your provider to send mail and signs every message with your own domain. On Microsoft 365, check that DKIM shows as enabled for your domain in the admin centre — the records on their own do not do it.

You should also have your MX and autodiscover records in place — see the related email DNS article if you have not added them yet. If the zone still holds the records for the included mailboxes (MX mx.maxinodes.com, SPF include:_spf.maxinodes.com), replace them as that article describes. A domain can have only one SPF record, so if your website still sends mail from our server, keep include:_spf.maxinodes.com inside the provider's SPF record.

Step 3 — Start DMARC at p=none

Begin in monitor-only mode so you can watch what happens without blocking any legitimate email.

In your client area DNS manager, add a TXT record at the host _dmarc. If the zone already has one, edit it instead: a domain can have only one DMARC record.
Use a starting value such as:

v=DMARC1; p=none; rua=mailto:you@yourdomain.com

Replace the address with a mailbox you check. The rua address receives the daily reports.
Save and leave it running for a couple of weeks.

Result: DMARC is live in monitor mode. No mail is blocked yet, and reports start arriving.

Step 4 — Tighten DMARC over time

Read the reports to confirm all your legitimate senders (your provider, plus any newsletter or invoicing tools) pass SPF or DKIM.
When everything you care about passes, raise the policy to p=quarantine (failures go to spam).
After more monitoring, move to p=reject (failures are blocked) for the strongest protection.

Result: Only authenticated mail is delivered as you, and forged mail is rejected.

Troubleshooting this task

Records do not seem to apply. DNS changes usually take minutes to a few hours, up to 24-48 hours in the worst case, depending on TTL. Use a public DNS-checker tool to confirm the record is visible.
You edited DNS in cPanel. The cPanel zone editor does not control your live DNS here. Always add email records in the client area.
Legitimate email is going to spam after you tighten DMARC. Drop back to p=none, check your reports for a sender that fails both SPF and DKIM, and add or fix that source before tightening again.
You have more than one SPF record. A domain may have only one SPF TXT record. Merge multiple include: entries into a single v=spf1 ... line.
Two competing SPF qualifiers. Microsoft 365 templates end in -all and Google in ~all; do not mix providers' values on the same domain.