Blog · Dmarc

How to Align DMARC and SPF When Using Google Workspace with HostGator

Your domain sends email through Google Workspace. Your DNS sits at HostGator. Your DMARC record exists but your legitimate Google Workspace email is still failing validation at receiving servers. This combination trips up a lot of small business setups. Here is what actually causes it and how to fix it.

Why Google Workspace and HostGator Break DMARC Alignment

Google Workspace does not send from your domain directly. It routes your email through Google's own mail servers and signs it with Google's DKIM keys before it leaves. HostGator does not do anything to that email. HostGator is just where your DNS records live.

When a receiving mail server checks your DMARC record, it looks at the From header domain, the domain in the SPF result, and the domain in the DKIM signature. All three need to align: the From header on the envelope, the SPF-authenticated domain, and the DKIM-authenticated domain.

If Google Workspace is set up correctly, the DKIM signature uses your domain and the SPF result shows Google's servers as the sending source. But if either authentication mechanism is missing, misconfigured, or using the wrong alignment mode, your legitimate email fails DMARC even though nothing is spoofed.

The confusion usually starts here: SPF passes at the SMTP level but DMARC still fails because the aligned domain does not match. Or DKIM is signed but with a subdomain selector that the DMARC policy does not align with.

Relaxed vs Strict Alignment: The Setting That Matters Most

DMARC has two alignment modes for both DKIM and SPF: relaxed (r) and strict (s).

Relaxed alignment means the top-level organizational domain must match. A message signed with d=mail.example.com and sent from example.com passes relaxed alignment because the organizational domain is the same.

Strict alignment means the domains must match exactly. mail.example.com does not pass strict alignment against a From header of example.com. The selector makes the difference.

For most Google Workspace setups on HostGator, relaxed alignment is the right setting. You want aspf=r and adkim=r in your DMARC record. Strict alignment requires that every sending source uses the exact same domain in both its From header and its DKIM selector. If your Google Workspace DKIM uses a selector like google._domainkey.example.com, strict alignment will only pass when that selector domain exactly matches your From header domain.

Use strict only if you control every sending system and are certain they all use exact domain matches. For everyone else running Google Workspace plus a web host, relaxed alignment is the practical choice.

Step 1: Verify Your Google Workspace DKIM Setup

Google Workspace signs outbound email by default, but you need to generate a DKIM TXT record and publish it in your DNS at HostGator. Here is how.

In the Google Admin console, go to Apps > Google Workspace > Gmail > Authenticate email. Enable DKIM signing. Google generates a TXT record with a selector name and the public key.

The record looks like this:


Type: TXT
Host: google._domainkey
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...

Add this exactly as shown to your HostGator DNS panel. Log into HostGator, go to your domain's DNS zone editor, and create a new TXT record. Paste the selector name as the host and the full value as the record content. Save it and wait for propagation. A TTL of 3600 seconds works for a first setup. You can increase it later once things are stable.

After adding the record, use a DKIM checker to confirm the record is live before assuming it is working.

Step 2: Confirm Your Google Workspace SPF Record

Google Workspace uses a specific SPF include mechanism. Your SPF record at HostGator needs to include Google's SPF servers. The record looks like this:


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

If you already have an SPF record and are adding Google Workspace to it, your full record might look like:


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

One thing to watch: the 10-lookup limit. RFC 7208 limits SPF records to 10 DNS lookups. Each include() counts as one. If your SPF record has too many includes, receivers treat it as a permerror and default to softfail behavior. Count your includes before publishing. Most small business setups stay well under the limit, but it is worth checking.

Step 3: Write Your DMARC Record for HostGator

When Google Workspace is your only outbound email source, the minimum viable DMARC record looks like this:


v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r; pct=100

Breakdown:

  • v=DMARC1: required version tag
  • p=none: start in monitoring mode, do not reject or quarantine yet
  • rua: aggregate report destination
  • adkim=r: relaxed DKIM alignment
  • aspf=r: relaxed SPF alignment
  • pct=100: apply to all messages (note: pct is advisory; most major receivers honor it but not all do)

The rua address receives aggregate reports from participating receivers. These reports tell you which sending sources are passing and failing DMARC. Read them before you move to p=quarantine or p=reject.

With Google Workspace as your sole sending source and DKIM and SPF correctly configured, your legitimate email should pass DMARC under this record.

Step 4: Add the DMARC TXT Record in HostGator

In HostGator's cPanel, go to Zone Editor (or Advanced DNS Zone Editor depending on your plan). Find your domain and add a new TXT record.

  • Name/Host: _dmarc
  • TTL: 3600
  • Type: TXT
  • Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r; pct=100

Replace dmarc-reports@example.com with your actual report destination address. That mailbox does not need to be hosted at Google Workspace. It just needs to be able to receive plain text aggregate reports.

After saving, use a DMARC lookup tool to confirm the record is visible in DNS. Propagation usually takes under an hour on HostGator but can take up to 48 hours in edge cases.

Step 5: Test Before Going to p=reject

Before moving from p=none to p=quarantine or p=reject, read your DMARC aggregate reports. They show you exactly which sending sources are passing and which are failing.

Open your reports in DMARCFlow first. DMARCFlow parses aggregate reports and breaks down passing and failing sources by domain, IP, and date. When you first set up Google Workspace DKIM and SPF on HostGator, you want to confirm that your own Google Workspace sending shows as pass in the reports. If something is failing, the breakdown tells you which alignment check is the problem and which domain or IP is involved.

Without reading reports, you are guessing. With reports, you move to p=reject with actual data showing that your own email is not the one failing.

Common Failure Modes and How to Fix Them

SPF includes too many lookups
If your SPF record exceeds 10 DNS lookups, receivers treat it as a permerror and default to softfail. Run an SPF record checker and count the includes. If you are over the limit, consolidate by removing duplicate includes or switching to a redirect mechanism.

DKIM key not propagated
You added the Google DKIM TXT record to HostGator but it is not resolving yet. DNS propagation is not instant. Check with dig or an online TXT lookup tool. If the record is there but DKIM still fails, verify you used the correct selector name (google._domainkey) and that you did not add extra whitespace or line breaks to the value.

DKIM selector domain mismatch
If your DKIM signature uses a subdomain selector that does not align with your From header domain, DMARC fails even if the signature is valid. Relaxed alignment (adkim=r) fixes this for most cases. If you are using strict alignment and have DKIM selectors on subdomains, switch to relaxed.

Subdomain alignment issues
If you send email from both example.com and subdomain.example.com, and your DMARC record applies to example.com, subdomain email fails strict alignment. Use adkim=r and aspf=r when you have subdomain senders.

DMARC record syntax errors
Missing semicolons, incorrect tags, or typos in the DMARC record cause receivers to ignore it entirely. Use a DMARC record syntax checker before publishing. A broken DMARC record is worse than no record at all because it gives you no visibility into who is sending as your domain.

Quick-Reference Checklist

Before moving from p=none to p=quarantine or p=reject, confirm each of these:

  • [ ] Google Workspace DKIM is enabled in the Admin console
  • [ ] DKIM TXT record is published in HostGator DNS and resolves correctly
  • [ ] SPF record at HostGator includes _spf.google.com
  • [ ] SPF record has 10 or fewer DNS lookups
  • [ ] DMARC record is published at _dmarc.yourdomain.com and resolves correctly
  • [ ] DMARC record uses adkim=r and aspf=r (relaxed alignment)
  • [ ] Aggregate reports are arriving at your rua address
  • [ ] DMARC reports show Google Workspace passing DMARC alignment
  • [ ] No third-party senders are failing DMARC before you escalate policy
  • [ ] DMARCFlow confirms all legitimate sources pass

If all boxes check out, move from p=none to p=quarantine first. Watch delivery for a week. If no issues surface, move to p=reject.

Getting DMARC alignment right across Google Workspace and HostGator is a solved problem. The steps are sequential and the failure modes are predictable. The part most people skip is reading the reports before they escalate. That is the step that tells you whether the fix actually worked.