Email Deliverability Setup

Updated June 2, 2026

When Marmend sends emails through your team's Gmail accounts (via the Gmail integration), the receiving mail server checks whether your domain is authorized to send that mail. If your domain isn't properly authenticated, emails to candidates may land in spam — or get blocked entirely by stricter recipients like Outlook, Office 365, or corporate email gateways.

This guide walks you through the three DNS records your domain needs so candidate emails reliably reach the inbox.

Time required: ~15 minutes Who does this: Your Google Workspace admin + whoever manages your domain's DNS Frequency: One-time setup per domain

Why This Matters

Modern email providers (Gmail, Outlook, Yahoo, etc.) use three standards to verify that an email actually comes from the domain it claims to come from:

Standard	What it does	What happens if missing
SPF	Lists which servers are allowed to send mail for your domain	Recipients may mark emails as suspicious
DKIM	Cryptographically signs each outgoing email with your domain's key	Emails appear as "sent via gmail.com" instead of your domain
DMARC	Tells recipients what to do when SPF or DKIM fails	Recipients use their own (often stricter) defaults

When Marmend sends an email through your recruiter's Gmail account (e.g. [email protected]), the email passes through Google's mail servers. Without these records published, Google has to use its generic signing key instead of your domain's key. The recipient sees the email is signed by gappssmtp.com rather than yourcompany.com, which lowers trust and increases spam-folder risk.

The Practical Impact

Setup	Where your emails land
No DKIM, no SPF	Often spam folder, sometimes blocked by strict filters
SPF only	Better, but still degraded — emails marked as "via gmail.com"
DKIM only	Acceptable for most recipients
DKIM + SPF + DMARC	Inbox in virtually all cases

Before You Start

You'll need:

Google Workspace Super Admin access for your domain (yourcompany.com)
DNS access for your domain — this is usually your domain registrar (GoDaddy, Namecheap, Google Domains, Cloudflare, AWS Route 53, etc.) or your IT team
About 15 minutes — plus up to 48 hours for DNS changes to propagate worldwide

If you don't manage your own DNS, send your IT team or domain administrator a link to this guide and ask them to apply the three records below.

Step 1 — Generate and Publish Google DKIM

DKIM is the most important record. It lets Google sign emails with your domain's cryptographic key instead of a generic one.

1.1 Generate the key in Google Workspace Admin

Sign in to Google Workspace Admin Console as a Super Admin.
In the left sidebar, go to Apps → Google Workspace → Gmail.
Click Authenticate email.
At the top, make sure the correct domain is selected (usually yourcompany.com).
Click Generate New Record.
Choose key length: 2048-bit (recommended).
Prefix selector: leave as **google** (default).
Click Generate.

Google displays the record you need to add to your DNS:

Field	Example value
Hostname/Name	`google._domainkey`
Type	TXT
Value	`v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...` (very long string)

Keep this tab open — you'll need to come back to it after publishing the record.

1.2 Add the record to your DNS

The exact UI varies by your DNS provider, but the values you enter are always the same.

Sign in to your DNS provider (where you manage your domain).
Open the DNS records page for yourcompany.com.
Add a new TXT record:
- Name / Host: google._domainkey (some providers want only this; others want google._domainkey.yourcompany.com)
- Type: TXT
- Value / Content: paste the long string from Google (everything starting with v=DKIM1;)
- TTL: leave default (usually 1 hour or "Auto")
Save.

1.3 Activate in Google Workspace

Go back to the Google Admin tab where you generated the key.
Wait ~10 minutes for DNS to propagate.
Click Start Authentication.
The status should change to "Authenticating email" within a few minutes.

If you see an error like "DNS record not found", DNS hasn't propagated yet. Wait another 10 minutes and try again.

Step 2 — Set Up SPF

SPF lists which mail servers are authorized to send mail as your domain. For Marmend, you need to authorize Google's mail servers (since the actual sending happens through your team's Gmail accounts).

2.1 Check your current SPF record

Open a terminal (Mac/Linux) or PowerShell (Windows).
Run:
```
nslookup -type=TXT yourcompany.com
```
Look in the output for a line starting with v=spf1. That's your current SPF record.

You'll see one of three situations:

Situation A — No SPF record exists

You need to create an SPF record. Go to Step 2.2.

Situation B — SPF already includes Google

If you see include:_spf.google.com in the existing record, you're done with this step. Skip to Step 3.

Situation C — SPF exists but doesn't include Google

You need to add Google to the existing record. Example existing record:

v=spf1 include:_spf.protonmail.ch ~all

You'd update it to:

v=spf1 include:_spf.google.com include:_spf.protonmail.ch ~all

Important: a domain can have only one SPF record. Don't add a second one — update the existing.

2.2 Add or update the SPF record

Recommended SPF for a domain using Google Workspace + Marmend:

v=spf1 include:_spf.google.com ~all

If you also send transactional email through another service (Mailgun, SendGrid, AWS SES, etc.), include those too:

v=spf1 include:_spf.google.com include:amazonses.com include:mailgun.org ~all

To add or update:

In your DNS provider, find the existing TXT record at the apex (@ or yourcompany.com) starting with v=spf1. If none exists, add a new TXT record at the apex.
Type: TXT
Name / Host: @ (or leave blank — refers to the apex)
Value: the SPF string above
TTL: default
Save.

Note about **\~all** vs **-all**: ~all means "soft fail" (treat unauthorized senders as suspicious but don't reject). -all means "hard fail" (reject entirely). Start with ~all for safety; consider -all only after several weeks of confirmed clean delivery.

Step 3 — Set Up DMARC (Recommended)

DMARC tells recipients what to do when SPF or DKIM checks fail, and gives you reports on email activity for your domain.

3.1 Add the DMARC record

Add a TXT record:

Field	Value
Name / Host	`_dmarc`
Type	TXT
Value	`v=DMARC1; p=none; rua=mailto:[email protected]`
TTL	default

Replace [email protected] with an actual mailbox you check (or skip the rua= part entirely if you don't want reports).

3.2 What the policy options mean

Policy (`p=`)	Behavior
`none`	Monitor only. No emails are blocked. Start here.
`quarantine`	Recipients put failing emails in spam.
`reject`	Recipients block failing emails entirely.

Recommendation:

First 30 days: p=none — monitor, no blocking. Check reports for anything misconfigured.
After 30 days of clean reports: upgrade to p=quarantine.
After 60+ days of stable operation: upgrade to p=reject for maximum protection against impersonation.

How to Verify Everything Works

After all three records are in place and DNS has propagated (wait at least 1 hour, ideally a full day):

Method 1 — Send a test email through Marmend

In Marmend, open any candidate.
Click Send Email and compose a quick test message.
Send it to your own external Gmail address (e.g. your personal @gmail.com).
Open the email in Gmail.
Click the three-dot menu (⋮) → Show original.
Look at the top of the message for the Authentication-Results line.

You should see:

Authentication-Results: mx.google.com;
   dkim=pass [email protected]   ← signed by YOUR domain (not gappssmtp.com)
   spf=pass (google.com: domain of [email protected] designates ... as permitted sender)
   dmarc=pass header.from=yourcompany.com

All three PASS = your setup is complete.

Method 2 — Use an online checker

Visit mxtoolbox.com and run:

SPF check: enter yourcompany.com → should return a valid SPF record including _spf.google.com.
DMARC check: enter yourcompany.com → should return a valid DMARC record.
DKIM check: enter google._domainkey as the selector → should return your DKIM record.

Troubleshooting

"Mailed by: gappssmtp.com" still appears

DKIM either isn't published yet, or Google hasn't picked it up. Check:

Has DNS propagated? Run nslookup -type=TXT google._domainkey.yourcompany.com — you should see the long DKIM string. If not, wait another hour.
Did you click Start Authentication in Google Admin (Step 1.3)? Until you do, Google won't use the key even if it's published.
Has the integration in Google Admin moved to "Authenticating email"? If still "Not authenticating", click Start Authentication again.

`dmarc=fail` in test email

Common causes:

SPF doesn't authorize the sending server: make sure your SPF includes _spf.google.com.
DKIM is signing as **gappssmtp.com** instead of your domain: complete Step 1 (DKIM setup) first.
You have a stale DMARC record: check there's only one DMARC TXT record at _dmarc.yourcompany.com.

Multiple SPF records error

A domain may only have one SPF record. If nslookup shows two records starting with v=spf1, you must merge them into one. Example:

❌ Two records (wrong):

v=spf1 include:_spf.google.com ~all
v=spf1 include:amazonses.com ~all

✅ One record (correct):

v=spf1 include:_spf.google.com include:amazonses.com ~all

Changes not appearing

DNS propagation can take up to 48 hours, though usually 1-4 hours. Use dnschecker.org to see if your records are visible from different parts of the world.

FAQ

Why do I need this if Marmend already authenticates its own emails?

When Marmend sends a system email (notifications, password resets, etc.) it uses Marmend's own domain — those are handled by Marmend's infrastructure. But when a recruiter sends a personalized email through the Gmail integration, the email comes from their Gmail account at your domain. The receiving server checks your domain's authentication, not Marmend's.

Will this affect emails I send manually through Gmail?

Yes — and that's a good thing. After this setup, every email sent from any of your team's @yourcompany.com Gmail accounts (whether through Marmend, the Gmail web interface, or a mobile app) will be properly authenticated. Higher deliverability across the board.

What if our domain DNS is managed by a complicated provider (Cloudflare, Route 53, internal nameservers)?

The values you publish are the same regardless of provider. The only difference is the UI for adding records. If your provider isn't covered here, your DNS admin can map the field names:

Concept	Field name varies as
Record type	"Type" or "Record type"
Subdomain	"Name", "Host", "Hostname", "Record name"
Record value	"Value", "Data", "Content", "Points to"
Time-to-live	"TTL", "Time to live", "Cache time"

Do I need to do this for every Workspace user?

No — DKIM/SPF/DMARC are domain-level records. Once published, they apply to all users on that domain automatically.

What about subdomains (e.g. `mail.yourcompany.com`)?

Most teams only send from the main domain. If you send from a subdomain, that subdomain needs its own SPF + DKIM + DMARC records. The same setup process applies, just with the subdomain name.

How do I check Marmend has the correct email config on its side?

Marmend's outbound infrastructure (notifications, system emails) is fully authenticated under marmend.com — this is managed by the Marmend team and requires no action from you.

What's Next

After completing this setup:

Monitor your DMARC reports (if you configured rua=) for the first few weeks. Look for any "fails" from senders you don't recognize — could indicate someone spoofing your domain.
After 30 days of clean operation, upgrade your DMARC policy from p=none to p=quarantine.
After another 30 days, upgrade to p=reject for maximum spoofing protection.
Consider also setting up BIMI (Brand Indicators for Message Identification) — shows your logo next to your emails in Gmail. Requires DMARC at p=quarantine or p=reject first.