How to Configure SPF, DKIM, and DMARC for Google Workspace on Hostinger DNS

Google Workspace Email Authentication

How to Configure SPF, DKIM, and DMARC Safely When DNS Is Managed by Hostinger

A complete beginner-friendly guide to diagnosing Gmail authentication failures, understanding domain registration versus DNS hosting, adding the correct records, avoiding email disruption, and verifying that SPF, DKIM, and DMARC all pass.

Contents

• The original problem
• SPF, DKIM, and DMARC explained
• What the Gmail results meant
• Where DNS changes must be made
• Fail-safe rollout strategy
• Records to create
• Hostinger step-by-step
• Google Admin DKIM setup
• Testing and verification
• Troubleshooting
• Common mistakes
• Clean setup for a new domain
• Quick checklist

The Original Problem

Email sent from a custom domain through Google Workspace was reaching some providers but failing or being rejected by Gmail. The first challenge was determining whether the message was properly authenticated. Gmail's Show original page eventually reported:

SPF: NONE
DKIM: PASS with domain [GOOGLE_FALLBACK_DOMAIN].gappssmtp.com
DMARC: FAIL

Those results revealed that the message was cryptographically signed, but the signing domain did not match the visible From domain. SPF was also missing for the actual sending path. Because neither method aligned with the From domain, DMARC failed.

Important distinction:

A Google sending-quota error such as 421-4.7.28 is a separate problem. Correcting SPF, DKIM, and DMARC improves authentication and deliverability, but it does not remove account, Google Group, or bulk-sending limits.

SPF, DKIM, and DMARC in Plain English

Technology	What it checks	What must happen for success	Typical DNS location
SPF	Whether the sending server is authorized to send for the domain.	The envelope or Return-Path domain must be authorized, and for DMARC it must align with the From domain.	TXT record at the root, usually @.
DKIM	Whether the message has a valid cryptographic signature.	The signature must validate; for DMARC, the DKIM signing domain should align with the From domain.	TXT record such as google._domainkey.
DMARC	Whether SPF or DKIM passes and aligns with the visible From domain.	At least one aligned method must pass.	TXT record at _dmarc.

DMARC does not independently authenticate a message. It evaluates the aligned result of SPF and DKIM. This explains how DKIM can say PASS while DMARC still says FAIL: the DKIM signature may be valid but signed by a different domain.

What the Gmail Results Meant

SPF: NONE

Gmail could not find a usable SPF authorization for the message's sending domain. This commonly happens when no SPF record exists, the wrong provider is authorized, or DNS is being edited at the wrong host.

DKIM: PASS, but not aligned

Google had signed the message using a fallback gappssmtp.com domain rather than the custom domain. The signature was valid, but it did not satisfy DMARC alignment for mail sent as [YOUR_EMAIL]@[YOUR_DOMAIN].

DMARC: FAIL

Neither SPF nor DKIM passed in an aligned way. This was the main authentication failure visible to Gmail.

Target result after configuration

SPF: PASS
DKIM: PASS with domain [YOUR_DOMAIN]
DMARC: PASS

Domain Registrar vs. DNS Host: The Critical Discovery

The domain was registered at GoDaddy, but its nameservers pointed to Hostinger. That means GoDaddy handled registration and renewal, while Hostinger controlled the live DNS zone.

Service	Role	Where changes belong
GoDaddy	Domain registrar	No SPF, DKIM, or DMARC changes while Hostinger nameservers are active.
Hostinger	Active DNS manager	Add and edit TXT records here.
Google Workspace	Email provider	Generate DKIM and activate signing here.

Do not change nameservers merely to add email authentication.

Changing nameservers can disconnect the website, email, verification records, and other services. Keep the current nameservers and edit TXT records at the active DNS host.

A Fail-Safe Rollout Strategy

1. Confirm email works before changing anything

   Send a test message to the domain and reply from the domain. Keep both messages as a baseline.

2. Back up the DNS zone

   Take screenshots showing all TXT and MX records, including names, values, priorities, and TTLs.

3. Do not touch mail-routing records

   Leave MX, A, AAAA, CNAME, NS, and existing verification records unchanged.

4. Change one authentication layer at a time

   Handle SPF first, then DKIM, then leave DMARC in monitoring mode until everything passes.

5. Test after every change

   Send a brand-new message to a separate Gmail inbox and inspect Show original.

The Required DNS Records

SPF for Google Workspace only

Type: TXT
Name: @
Content: v=spf1 include:_spf.google.com ~all
TTL: 3600

SPF during a Microsoft 365 to Google Workspace transition

If Microsoft 365 may still send mail for the domain, keep both services authorized temporarily:

Type: TXT
Name: @
Content: v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all
TTL: 3600

Only one SPF record should exist for the root domain.

Do not add a second TXT record beginning with v=spf1. Edit the existing SPF record so every legitimate sender is included in the same policy.

DKIM

Type: TXT
Name: google._domainkey
Content: [PASTE THE FULL VALUE GENERATED BY GOOGLE ADMIN]
TTL: 3600

The DKIM value is unique to the Google Workspace domain. It begins with something like:

v=DKIM1; k=rsa; p=...

The public DKIM key is meant to be published in DNS, but a reusable article should not expose a domain-specific key. Always generate a fresh key from the appropriate Google Admin console.

DMARC monitoring policy

Type: TXT
Name: _dmarc
Content: v=DMARC1; p=none;
TTL: 3600

p=none is the safest starting point. It evaluates authentication without instructing receiving systems to quarantine or reject failing mail.

Hostinger DNS: Step-by-Step

1. Sign in to Hostinger hPanel.
2. Open Domains.
3. Select [YOUR_DOMAIN].
4. Open DNS / Nameservers or DNS Zone Editor.
5. Filter the list by TXT.
6. Check for a root record whose content starts with v=spf1, a record named google._domainkey, and a record named _dmarc.

If an SPF record already exists

Edit it instead of adding another. For example, an existing Microsoft-only SPF record:

v=spf1 include:spf.protection.outlook.com -all

can be changed during a transition to:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

Once it is confirmed that Microsoft 365 no longer sends any mail, the Microsoft include can be removed, leaving only Google.

Adding DKIM in Hostinger

1. Search for google._domainkey.
2. If it does not exist, click Add record.
3. Select TXT.
4. Set the name to google._domainkey.
5. Paste the complete Google-generated DKIM value into the content field.
6. Set TTL to 3600 or leave the Hostinger default.
7. Leave TXT priority at 0 if Hostinger displays that field; priority is not meaningful for TXT records.
8. Save the record.

Hostinger usually appends the domain automatically.

Enter google._domainkey, not google._domainkey.[YOUR_DOMAIN], unless the interface explicitly requires the full hostname.

Google Admin: Generate and Activate DKIM

1. Open the correct Admin account

   Sign in with a Super Administrator or an account that has the necessary Gmail settings privileges.

2. Navigate to Gmail authentication

   Open Apps → Google Workspace → Gmail → Authenticate email.

3. Select the custom domain

   Choose [YOUR_DOMAIN], not a temporary or fallback Google domain.

4. Generate the DKIM record

   Click Generate new record, select a 2048-bit key, and use the selector google.

5. Publish the DNS record

   Add the provided hostname and full TXT value in Hostinger.

6. Start authentication

   Return to Google Admin and click Start authentication only after the DNS record has been saved.

Do not repeatedly generate new DKIM keys when DNS is slow.

If Google cannot find the record immediately, wait for propagation and try Start authentication again. Generating another key can make troubleshooting harder.

How to Test the Configuration Correctly

1. Send a brand-new message from [YOUR_EMAIL]@[YOUR_DOMAIN] to a separate Gmail account.
2. Open the message in the recipient's Inbox.
3. Click the three-dot menu near Reply.
4. Select Show original.
5. Look for SPF, DKIM, and DMARC at the top.

Do not inspect the Sent-folder copy or a bounce notice.

Gmail adds useful Authentication-Results when it receives a message. A sent copy or rejected message may not contain the information needed for diagnosis.

The desired result is:

SPF: PASS
DKIM: PASS with domain [YOUR_DOMAIN]
DMARC: PASS

Also perform practical delivery tests:

• Gmail to the domain
• Reply from the domain to Gmail
• Domain to Outlook
• One mail-merge test to a single recipient
• One ordinary plain-text message

Troubleshooting Guide

SPF still shows NONE

• Confirm the TXT record was added at the active DNS provider, not merely the registrar.
• Confirm the name is @.
• Confirm there is only one SPF record.
• Wait for DNS propagation.
• Send a new message after the DNS change.

SPF shows FAIL

• The actual sender may not be included in SPF.
• A website form, CRM, mail-merge system, or legacy provider may be sending independently.
• Review all services that send as the domain before using a strict -all policy.

DKIM passes with gappssmtp.com instead of the custom domain

Google is using a fallback signature. Generate a custom-domain DKIM key, publish it under google._domainkey, and click Start authentication in Google Admin.

Google Admin cannot find the DKIM record

• Verify the TXT name is exactly google._domainkey.
• Verify the entire key was pasted without missing characters.
• Do not add extra quotation marks or line breaks.
• Do not duplicate the full domain in the name field.
• Wait for DNS propagation before retrying.

DMARC still fails after DKIM is enabled

• Send a brand-new message; old messages do not change retroactively.
• Confirm DKIM shows the custom domain, not only a fallback domain.
• Confirm the visible From domain matches the DKIM signing domain or aligned SPF domain.
• Check that the message was not resent or modified by an intermediary.

Email reaches Outlook or Yahoo but not Gmail

Providers enforce policies differently. Gmail may reject or defer mail because of authentication, reputation, quota, or bulk-sender requirements even when another provider accepts it. Authentication must be fixed first, but sender reputation and sending limits may still need separate attention.

Common Mistakes and Why They Fail

Mistake	Why it is risky	Correct approach
Editing DNS at the registrar while another provider hosts DNS	The changes never become active.	Edit records where the nameservers point.
Creating two SPF records	SPF evaluation can return a permanent error.	Combine all authorized senders in one SPF record.
Replacing Microsoft SPF with Google without checking legacy senders	Microsoft-sent mail may begin failing.	Authorize both during transition, then simplify later.
Adding DKIM but not clicking Start authentication	Google may continue using fallback signing.	Publish the record, then activate it in Google Admin.
Using p=reject too early	Legitimate mail may be rejected before all senders are aligned.	Begin with p=none.
Checking the Sent-folder copy	It may not show Gmail's receiving-side authentication result.	Inspect the recipient Gmail inbox copy.
Changing MX records while fixing authentication	Incoming mail can stop working.	Leave MX records unchanged unless migrating mail providers deliberately.

Clean Setup for a Brand-New Google Workspace Domain

For a new domain where Google Workspace is the only email provider, the authentication records are straightforward:

SPF
Type: TXT
Name: @
Content: v=spf1 include:_spf.google.com ~all
TTL: 3600

DKIM
Type: TXT
Name: google._domainkey
Content: [GOOGLE-ADMIN-GENERATED VALUE]
TTL: 3600

DMARC
Type: TXT
Name: _dmarc
Content: v=DMARC1; p=none;
TTL: 3600

A new Google Workspace domain also needs Google's MX records for receiving mail. SPF, DKIM, and DMARC do not replace MX records.

Do not copy a DKIM value from another domain.

Each domain's DKIM public key must be generated in that domain's own Google Admin console.

Useful Official References

• Google Workspace: Set up SPF
• Google Workspace: Set up DKIM
• Google Workspace: Set up DMARC
• Hostinger: Manage DNS records
• Hostinger: Manage TXT records

Quick Final Checklist

• DNS changes were made at the active DNS host.
• MX, A, CNAME, NS, and verification records were not modified.
• Only one SPF record exists.
• SPF includes every legitimate sending provider.
• Google DKIM was generated with a 2048-bit key.
• google._domainkey contains the full generated value.
• Start authentication was clicked in Google Admin.
• DMARC remains at p=none during initial monitoring.
• A new Gmail test shows SPF PASS.
• A new Gmail test shows DKIM PASS with the custom domain.
• A new Gmail test shows DMARC PASS.
• Bulk sending limits and reputation issues are treated separately.

Final conclusion

The safest method is to preserve incoming-mail routing, make TXT-only changes at the active DNS provider, keep one combined SPF record, activate custom-domain DKIM from Google Admin, and retain DMARC in monitoring mode until repeated tests pass.

This article uses placeholders such as [YOUR_DOMAIN] and [YOUR_EMAIL] to protect private account information while preserving the complete technical process.