How to set up DMARC/DKIM/SPF for ServiceNow
ServiceNow can send workflow notifications, ticket updates, incident mail, approvals, and case messages using a customer From domain. Recipient systems trust those messages when SPF, DKIM, and DMARC pass for that domain. I set this up by confirming the ServiceNow sending path, publishing the ServiceNow-provided DNS records, then using DMARC reports before moving the domain to p=reject.
- Use ServiceNow guidance: ServiceNow's public DKIM and SPF post says the order is to get the DKIM selector and public key, publish DKIM and SPF, then reprovision email.
- Keep one SPF record: Merge ServiceNow into the existing root-domain SPF record instead of adding a second TXT SPF record.
- Treat DKIM as required: ServiceNow mail should have a valid DKIM signature for the customer From domain before DMARC enforcement.
- Start with reporting: Use p=none first unless the domain is already on quarantine or reject.
Add your domain
ServiceNow does not work like a bulk email platform where I simply paste a domain and get instant DNS values. The first job is to identify whether ServiceNow is sending through ServiceNow Cloud Email Services or through an SMTP account that your team owns. That choice decides which system provides the SPF and DKIM DNS records.
ServiceNow Email Accounts view showing the outbound sender configuration.
- Confirm the sender path: In ServiceNow, check outbound email settings and Email Accounts to see whether messages leave through ServiceNow-managed mail or your own SMTP server.
- Use a domain address: Set notification From and Reply-To values to addresses under the domain you control, such as support@example.com.
- Open a ServiceNow case: For ServiceNow Cloud Email Services, request email sender authentication for your From domain and ask for the DKIM selector, DKIM public key, SPF value, and reprovisioning step.
- Test in non-prod: Use a non-production instance and a safe subdomain first, then repeat the exact DNS pattern for production.
- Reprovision after DNS: After SPF and DKIM records resolve publicly, ask ServiceNow to complete the mail reprovisioning step so signing starts on outbound notifications.
Do not copy another tenant's SPF value
ServiceNow's SPF value depends on the outbound mail path. Use the ServiceNow SPF KB or your support case response, then publish that exact value in your DNS.
- ServiceNow-managed mail: Use the SPF and DKIM values ServiceNow gives you for the From domain.
- Customer SMTP mail: Use the SPF and DKIM values for that SMTP provider, because ServiceNow is only handing mail to your server.
Set up SPF
SPF authorizes the envelope sender, often seen in the Return-Path. ServiceNow can support a return path domain match when Cloud Email Services is provisioned for your domain, so I still publish the ServiceNow-provided SPF value even when DKIM is the main DMARC pass path.
|
|
|
|---|---|---|
ServiceNow SMTP | Add ServiceNow value | SPF pass |
Your SMTP | Use SMTP host | SPF pass |
Old return path | Keep DKIM passing | DMARC can pass |
Use the SPF action that matches how ServiceNow sends mail.
SPF record patternDNS
v=spf1 include:<servicenow-provided-include> include:_spf.example.net ~all
- Find the value: Use the ServiceNow support response for your instance and do not replace the placeholder above with a guessed include.
- Merge existing senders: Keep one SPF TXT record at the root sending domain and add the ServiceNow mechanism to it.
- Check lookup count: SPF stops at 10 DNS lookups, so remove stale includes before adding ServiceNow.
- Use soft fail first: Keep ~all during testing, then move to -all only when every sender is known.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
A valid SPF record does not satisfy DMARC unless the checked envelope domain matches the visible From domain. If ServiceNow mail passes DKIM for the visible From domain, DMARC can pass even when SPF shows a domain-match error. I still fix SPF because bounce handling and some filters use it.
Set up DKIM
DKIM is the most important ServiceNow authentication record because it signs the message with your domain. ServiceNow should provide a selector and public key. Your DNS host then publishes that key at the selector host under _domainkey.
ServiceNow support case requesting a DKIM selector and public key.
DKIM TXT patternDNS
selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=<public-key>"
- Request keys: Ask ServiceNow for the DKIM selector and public key for the exact From domain used by notifications.
- Publish the host: Create the TXT record at selector._domainkey, not at the root domain.
- Preserve the key: Paste the public key exactly as ServiceNow provides it and let your DNS host handle wrapping.
- Wait for signing: DKIM does not pass until DNS is live and ServiceNow has reprovisioned outbound email for the instance.
ServiceNow-managed mail
- DNS source: ServiceNow gives the DKIM selector, public key, and SPF value.
- Signing owner: ServiceNow signs outbound notifications after email is reprovisioned.
- Best check: Send a real incident or approval notification and inspect the headers.
Your own SMTP
- DNS source: Your SMTP service gives the SPF and DKIM records.
- Signing owner: Your SMTP service signs the message after ServiceNow hands it off.
- Best check: Check the SMTP account, DNS records, and final message headers together.
Set up DMARC
DMARC tells receivers what to do when ServiceNow mail cannot prove it belongs to the visible From domain. Start with p=none unless your domain already uses quarantine or reject. If it already uses either stronger policy, keep it there and fix ServiceNow until its mail passes.
Starting DMARC recordDNS
v=DMARC1; p=none; rua=mailto:dmarc@example.com
Use the DMARC record generator when you want this starting record with your real reporting address and optional failure reporting fields.
- Publish at the right host: Create one TXT record at _dmarc.example.com.
- Use a real rua: Replace dmarc@example.com with the mailbox or reporting address that collects aggregate reports.
- Check subdomains: A ServiceNow subdomain can inherit the root DMARC policy unless it has its own _dmarc record.
- Keep stronger policies: If the domain is already on p=quarantine or p=reject, do not lower it for ServiceNow.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
What ServiceNow DMARC changes
The ServiceNow DMARC KB is the support entry point for ServiceNow Cloud Email Services. I use it to confirm whether the instance needs a ServiceNow-side change after DNS is ready.
- DNS controls policy: Your domain's DMARC TXT record controls receiver handling.
- ServiceNow controls signing: ServiceNow must sign mail correctly for the From domain before enforcement is safe.
- Reports prove readiness: DMARC aggregate reports show whether ServiceNow is passing at real receiver scale.
- Headers prove a message: Authentication-Results headers show the result for a specific ServiceNow notification.
Verify and troubleshoot
Verification needs both DNS checks and a real ServiceNow notification. DNS can be perfect while the instance still uses an old mail route, so I always test the actual notification path that users receive.
ServiceNow email log showing a sent notification with authentication results.
|
|
|
|---|---|---|
SPF pass | Sender allowed | Keep record |
SPF fail | Value missing | Update SPF |
DKIM pass | Signature valid | Keep signing |
DKIM fail | Key wrong | Republish key |
DMARC fail | Domain mismatch | Fix DKIM |
Use final headers to separate DNS problems from ServiceNow provisioning problems.
- Send a real notification: Trigger an incident, approval, or case update from ServiceNow rather than sending a manual message from another sender.
- Read final headers: Check Authentication-Results at the recipient side for SPF, DKIM, and DMARC.
- Check one SPF record: Two root-domain SPF records cause permanent SPF errors.
- Check the selector: A selector typo breaks DKIM even when the public key value is correct.
- Check ServiceNow status: If DNS is correct but DKIM is absent, ask ServiceNow to confirm reprovisioning for the instance.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
The email tester is the fastest end-to-end check. Send a ServiceNow notification to the generated test address, then review the SPF, DKIM, DMARC, DNS, and content diagnostics for that exact message.
Common ServiceNow authentication failures
- Second SPF record: Merge records into one root-domain TXT record.
- No DKIM signature: DNS can be correct while ServiceNow still needs mail reprovisioning.
- Wrong From domain: A notification template can use a different sender than the domain you authenticated.
- Strict policy too early: Move to reject only after ServiceNow and every other sender passes consistently.
Get alerted when it breaks
ServiceNow email authentication can break after an instance change, DNS edit, sender address change, or mail route change. Suped's product turns aggregate DMARC monitoring into source-level issues, so the ServiceNow problem is visible before users report missing notifications.
Without monitoring
- Late detection: Authentication failures surface when users stop receiving notifications.
- Manual parsing: Raw XML reports must be opened and grouped by sender.
- Slow triage: ServiceNow failures get mixed with unrelated mail sources.
With Suped
- Real-time alerts: Get notified when ServiceNow authentication fails above your threshold.
- Source grouping: Separate ServiceNow from user mail, support mail, and marketing mail.
- Fix steps: See the DNS or sender action needed to restore passing mail.
- Automated issue detection: Suped flags failing ServiceNow traffic and gives steps to fix it.
- Unified checks: Suped brings DMARC, SPF, DKIM, blocklist (blacklist), and deliverability signals into one operational view.
- Hosted records: Hosted SPF, Hosted DMARC, and Hosted MTA-STS reduce DNS touchpoints once the domain is live.
- Multi-tenant work: MSPs and agencies can track ServiceNow authentication across many client domains without switching systems.
Secure your domain with p=reject
The target state is p=reject because it tells receivers to reject mail that cannot pass DMARC for your visible From domain. For ServiceNow, I move there only after real notification traffic passes DKIM consistently and no legitimate sender remains unknown.
DMARC policy stages
Move through policy stages only when reports show ServiceNow and every other sender passing.
Monitor
p=none
Collect reports without changing delivery.
Limited quarantine
pct=25
Sample enforcement after all core senders pass.
Full quarantine
pct=100
Send failing mail to spam for all traffic.
Reject
p=reject
Block mail that fails DMARC.
- Baseline first: Collect at least one normal business cycle of DMARC reports before enforcement.
- Confirm ServiceNow: Require DKIM pass for ServiceNow messages that use your domain.
- Remove unknown senders: Stop unauthorized sources or move legitimate sources into approved sending paths.
- Stage enforcement: Move to partial quarantine, then full quarantine, then reject.
- Protect subdomains: Use sp=reject only after subdomain senders are known.
Quarantine stageDNS
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com
Reject stageDNS
v=DMARC1; p=reject; rua=mailto:dmarc@example.com
Suped is the best overall DMARC platform for this rollout because it combines DMARC, SPF, DKIM, Hosted SPF, Hosted MTA-STS, SPF flattening, blocklist (blacklist) monitoring, real-time alerts, and multi-tenant reporting. Suped's Hosted DMARC lets teams stage policy changes without repeatedly editing DNS, which matters when ServiceNow is one of several production senders.
