Open the zone → Recommendations tab in my.cubepath.com.
Three TXT records decide whether mail claiming to come from your domain is believed: SPF, DKIM and DMARC. Without them, anyone can put your domain in the From: line and a fair number of receiving servers will deliver it; with them, forgeries fail and your own mail lands in inboxes instead of spam folders.
The tab checks which of the three your zone already has and offers to create the missing ones. Each shows as Configured once a matching record exists, so it doubles as a quick audit of a zone you inherited.
SPF
SPF lists the servers allowed to send mail for your domain. Add SPF creates a TXT record on @ with the strictest possible policy:
v=spf1 -all
That says nothing is allowed to send mail as this domain. It's the right starting point for a domain that doesn't send mail at all — a marketing site, a parked domain, an internal service — and it's the single most effective anti-spoofing record you can publish.
WarningIf the domain does send mail, edit the record before you're done. Add your provider's mechanism first — typically
include:for a hosted provider, orip4:/ip6:for your own server — and keep-allat the end. Publishing a barev=spf1 -allon a domain that sends mail makes every message you send fail SPF.
Edit it in the Records tab like any other TXT record.
DKIM
DKIM signs your outgoing mail so receivers can prove it wasn't altered in transit and really came from you. The key half is public and lives in DNS, at <selector>._domainkey.
You need two things from your mail provider — Google Workspace, Microsoft 365, Postmark, whoever sends for you: the selector (often default, google, or something provider-specific) and the public key. Paste both into the dialog and Add DKIM creates the record at the right name.
NoteThe key comes from your provider and only they can generate it. If you don't have one yet, enable DKIM in their admin panel first, then come back with the selector and key they give you.
DMARC
DMARC ties the other two together: it tells receiving servers what to do when SPF or DKIM fails, and where to send reports about it. Add DMARC creates a TXT record at _dmarc:
v=DMARC1; p=quarantine; rua=mailto:[email protected]
p=quarantine asks receivers to put failures in the spam folder rather than deliver them. You can supply your own reports address in the dialog; leave it empty and it defaults to dmarc@ your domain — which only helps if that mailbox exists.
The reports are aggregate XML from every receiver, and they're how you find the legitimate senders you forgot about before they start getting blocked.
The order to do this in
- 1Publish SPF and DKIM firstGet both correct for every system that sends as your domain: your mail provider, your ticketing system, your newsletter tool, your application's transactional mail.
- 2Add DMARC in monitoring modeStart at
p=nonewith a workingruaaddress, so you get reports without changing how anything is delivered. - 3Read the reports for a couple of weeksThey will show senders you'd forgotten. Fix their SPF and DKIM.
- 4Tighten the policyMove to
p=quarantine, thenp=rejectonce nothing legitimate is failing.
The button gives you p=quarantine straight away, which is right for a domain that doesn't send mail and aggressive for one that does. If your domain sends real mail, change it to p=none in Records until the reports are clean.
TipA domain that never sends mail still deserves all three. It's the cheapest way to stop your brand being used in phishing, and it takes about a minute here.