Implementing SPF, DKIM, and DMARC Validation for Inbound Email Authentication

How-To-Articles
1

Implementing SPF, DKIM, and DMARC Validation for Inbound Email Authentication

What This Guide Covers

This guide details the architectural configuration and DNS record requirements necessary to authenticate inbound email traffic within Genesys Cloud CX. By the end of this process, your organization will enforce strict sender verification policies that prevent spoofed support requests, ensure data integrity for automated ticketing workflows, and maintain compliance with enterprise security standards. You will have a fully operational inbound email channel that rejects or quarantines unauthenticated messages before they reach your agents or downstream CRM systems.

Prerequisites, Roles & Licensing

  • Licensing Tier: Genesys Cloud CX 1, 2, or 3. The Email feature is included in all standard CX tiers.
  • Administrative Permissions:
    • Administration > Channels > Email > Edit
    • Administration > Channels > Email > View
    • Administration > Users > Edit (to assign roles if necessary)
  • DNS Access: Full administrative access to the DNS zone of the domain you intend to use for inbound email (e.g., support@yourcompany.com).
  • External Dependencies:
    • A dedicated subdomain recommended for Genesys inbound traffic (e.g., email.yourcompany.com) to isolate DNS records from your primary corporate mail flow.
    • Knowledge of your current email security posture (existing SPF/DKIM/DMARC records).

The Implementation Deep-Dive

1. Architectural Strategy: Domain Isolation and Subdomain Routing

Before configuring Genesys, you must establish the DNS topology. The most critical architectural decision in email authentication is whether to use a shared domain or a dedicated subdomain.

The Trap: Configuring Genesys Email on a primary corporate domain (e.g., @yourcompany.com) that already hosts Exchange, Google Workspace, or Microsoft 365.

Why this fails: SPF records have a hard limit of 10 DNS lookups. If your primary domain already includes include:spf.protection.outlook.com and include:_spf.google.com, adding Genesys (include:spf.proofpoint.com or similar, depending on the specific Genesys partner integration) may exceed the lookup limit, causing SPF validation to fail for all outbound emails from your corporate domain. Furthermore, DMARC policies on the primary domain affect all mail. If Genesys sends a notification that fails DKIM alignment because the domain does not match, your entire corporate email flow could be impacted by a strict DMARC policy.

The Solution: Use a dedicated subdomain for inbound email processing. For this guide, we will assume the subdomain inbound.yourcompany.com. This isolates the authentication records. You can set a p=none or p=quarantine policy on the subdomain without risking your primary corporate communications.

Step 1.1: Define the Inbound Domain in Genesys

  1. Navigate to Admin > Channels > Email.
  2. Click Add Email Channel.
  3. Select Inbound Only (or Inbound and Outbound if you are also configuring outbound).
  4. Enter the Domain as inbound.yourcompany.com.
  5. Genesys will generate a unique Verification Token and provide specific DNS instructions. Do not proceed until these DNS records are propagated.

Architectural Reasoning: Genesys Cloud uses a verification token mechanism to prove domain ownership. This prevents unauthorized entities from configuring email channels for your domain. The token is typically implemented as a TXT record.

Step 1.2: Configure the DNS Verification Record

You must add the TXT record provided by Genesys to your DNS provider.

  • Record Type: TXT
  • Host/Name: _genesys_verification.inbound.yourcompany.com (or as specified by the UI)
  • Value: v=genesys-cloud-verify token=<unique_token_string>

Validation: Use dig or nslookup to verify propagation.

dig txt _genesys_verification.inbound.yourcompany.com

Wait until the response returns the exact token string before clicking Verify in the Genesys UI.

2. Configuring SPF (Sender Policy Framework)

SPF defines which IP addresses are authorized to send email on behalf of your domain. For inbound email, SPF is primarily used to validate the source of emails sent to your Genesys channel, ensuring that the email claiming to come from a customer’s domain is actually from that customer’s authorized servers. However, in the context of Genesys Inbound, SPF is also critical if you are using the same domain for outbound notifications.

The Trap: Using +all in your SPF record.

Why this fails: +all means “allow any server to send email from this domain.” This renders SPF useless for spoofing prevention. Attackers can trivially spoof your domain.

The Solution: Use -all (hard fail) or ~all (soft fail). For a dedicated inbound subdomain, -all is recommended to enforce strict security.

Step 2.1: Construct the SPF Record

If inbound.yourcompany.com is a dedicated subdomain solely for Genesys inbound traffic, you must authorize the Genesys Cloud email infrastructure. Genesys Cloud utilizes a third-party provider for email delivery (historically Proofpoint, but this can vary by region and contract). You must consult the current Genesys Cloud documentation for the specific include statement. As of the latest standard deployment, the include is often include:spf.proofpoint.com.

  • Record Type: TXT
  • Host/Name: inbound.yourcompany.com
  • Value: v=spf1 include:spf.proofpoint.com -all

Note on Lookup Limits: Ensure the total number of mechanisms (include, a, mx, ptr) in the final expanded SPF record does not exceed 10. You can test this using an SPF checker tool.

Architectural Reasoning: By restricting the SPF record to only include the Genesys provider, you ensure that any email claiming to originate from inbound.yourcompany.com must pass through the authorized infrastructure. This is critical for preventing “email injection” attacks where malicious actors attempt to bypass your inbound filters by spoofing internal addresses.

3. Configuring DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to emails, allowing the receiver to verify that the email was indeed authorized by the domain owner and has not been tampered with in transit.

The Trap: Generating a single DKIM key and using it for both inbound and outbound traffic, or failing to rotate keys.

Why this fails: If the private key is compromised (e.g., via a server breach), an attacker can sign malicious emails. Furthermore, if you use the same key for high-volume outbound marketing and critical inbound support, a high bounce rate on marketing emails can degrade the reputation of the key, causing inbound support emails to be flagged as spam.

The Solution: Generate a unique DKIM key pair for the Genesys Inbound channel. Genesys Cloud provides a mechanism to generate this key pair within the Email Channel configuration.

Step 3.1: Generate DKIM Keys in Genesys

  1. In the Email Channel configuration, navigate to the DKIM tab.
  2. Click Generate Key Pair.
  3. Genesys will display:
    • Selector: e.g., gen1
    • Public Key: A long string starting with v=DKIM1; k=rsa; p=...

Step 3.2: Publish the DKIM Public Key in DNS

You must add a TXT record containing the public key.

  • Record Type: TXT
  • Host/Name: gen1._domainkey.inbound.yourcompany.com (Note: The selector is prefixed with ._domainkey)
  • Value: v=DKIM1; k=rsa; p=<public_key_string_from_genesys>

Validation: Verify the record using DNS tools.

dig txt gen1._domainkey.inbound.yourcompany.com

Once propagated, click Verify in the Genesys UI.

Architectural Reasoning: DKIM validation occurs at the receiving end. When a customer sends an email to support@inbound.yourcompany.com, the customer’s mail server signs it with their DKIM key. Genesys validates this signature. If the signature is missing or invalid, Genesys can flag the email. Conversely, when Genesys sends a notification back to the customer, it signs the email with the inbound.yourcompany.com DKIM key. The customer’s mail server validates this signature against the public key in your DNS. If the key matches, the email is authenticated.

4. Configuring DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC ties SPF and DKIM together. It instructs receiving mail servers on what to do if an email fails SPF or DKIM checks.

The Trap: Setting p=reject immediately on a new domain.

Why this fails: If your SPF or DKIM records are misconfigured, or if legitimate third-party services (like CRM notifications) are not included in the SPF record, setting p=reject will cause those legitimate emails to be bounced. This can result in lost customer support tickets and angry users.

The Solution: Start with p=none to monitor reports, then move to p=quarantine, and finally p=reject once you have verified that all legitimate traffic is passing authentication.

Step 4.1: Construct the DMARC Record

  • Record Type: TXT
  • Host/Name: _dmarc.inbound.yourcompany.com
  • Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourcompany.com; ruf=mailto:dmarc-forensics@yourcompany.com; pct=100; adkim=s; aspf=s

Breakdown of Tags:

  • v=DMARC1: Version.
  • p=none: Policy. Monitor only. No action taken on failures.
  • rua=...: Aggregate report URI. Send daily XML reports to this address.
  • ruf=...: Forensic report URI. Send detailed failure reports for individual messages.
  • pct=100: Apply policy to 100% of messages.
  • adkim=s: DKIM alignment mode. s (strict) means the domain in the DKIM signature must exactly match the domain in the “From” header. r (relaxed) allows subdomain matching. For a dedicated subdomain, s is recommended.
  • aspf=s: SPF alignment mode. s (strict) requires the domain in the “Return-Path” to exactly match the “From” domain.

Architectural Reasoning: DMARC alignment is crucial for inbound email. If a customer sends an email from user@customer.com, and their mail server signs it with a DKIM key for customer.com, the alignment is strict. If they use a third-party service that sends from notifications.customer.com but signs with customer.com, strict alignment fails. By setting adkim=s and aspf=s on your inbound domain, you enforce high security. However, for the inbound flow, DMARC is primarily enforced by the sender’s domain. Your DMARC record on inbound.yourcompany.com is primarily for protecting your own domain against spoofing if you send outbound emails from this subdomain.

Important Note: For inbound email processing, Genesys Cloud validates the SPF and DKIM of the incoming email based on the sender’s domain. Your DMARC record on inbound.yourcompany.com does not affect the validation of incoming emails from customers. It only affects how other mail servers treat emails sent from inbound.yourcompany.com. Therefore, if you are only using the channel for inbound, the DMARC record is less critical for inbound validation but still necessary for domain reputation if you ever send outbound notifications from this domain.

5. Configuring Inbound Email Rules and Filtering

With DNS records in place, you must configure Genesys to act on the authentication results.

Step 5.1: Enable Authentication Checks

  1. In the Email Channel settings, navigate to Inbound Settings.
  2. Enable Validate Sender Authentication.
  3. Configure the action for failed authentication:
    • Reject: The email is bounced immediately.
    • Quarantine: The email is held for review by an admin.
    • Allow: The email is delivered, but flagged.

Recommendation: Start with Quarantine. This allows you to review false positives without losing customer communications. After a week of monitoring, if no legitimate emails are quarantined, switch to Reject.

Step 5.2: Configure Routing Rules

Use Genesys Architect to create routing rules based on authentication status.

  1. Create a new Flow for Email.
  2. Add a Decision node.
  3. Condition: Email Message > Authentication Status equals Failed.
  4. Action: Route to a Queue for Security Review or discard the message.
  5. Condition: Email Message > Authentication Status equals Passed.
  6. Action: Route to the standard Support Queue.

Architectural Reasoning: By routing failed authentication attempts to a separate queue, you create an audit trail. Agents can review these messages to identify potential spoofing attempts or misconfigured customer mail servers. This data can be used to update your blocklists or contact customers with instructions to fix their DNS records.

Validation, Edge Cases & Troubleshooting

Edge Case 1: SPF Lookup Limit Exceeded

The Failure Condition: Emails from legitimate senders are failing SPF validation, even though the SPF record appears correct.

The Root Cause: The SPF record for the sender’s domain contains more than 10 DNS lookups. This is a common issue with large enterprises that use multiple email providers (e.g., Office 365, Google, SendGrid, Mailchimp).

The Solution:

  1. Identify the sender’s domain.
  2. Use an SPF checker tool to analyze their record.
  3. If they exceed 10 lookups, the SPF check will return SoftFail or PermError.
  4. In Genesys, configure the authentication rule to treat PermError as Quarantine rather than Reject to avoid losing tickets from large enterprises with misconfigured DNS.
  5. Contact the sender’s IT department to consolidate their SPF record using CNAME flattening or by removing redundant includes.

Edge Case 2: DKIM Alignment Failure Due to Third-Party Forwarding

The Failure Condition: Legitimate customer emails are failing DKIM validation.

The Root Cause: The customer’s email is being forwarded through a third-party service (e.g., a ticketing system, a CRM, or a legacy mail gateway) that modifies the message headers or re-signs the email with a different key. This breaks the DKIM alignment because the “From” header domain does not match the domain in the DKIM signature.

The Solution:

  1. Check the DMARC forensic reports (ruf) to identify the specific failure reason.
  2. If the failure is due to alignment, consider relaxing the DKIM alignment mode to r (relaxed) in your DMARC record if you are the sender. However, for inbound validation, you cannot change the sender’s DMARC record.
  3. In Genesys, configure the authentication rule to allow emails with DKIM Pass but Alignment Fail if your business risk tolerance permits.
  4. Educate customers on the importance of preserving DKIM signatures when forwarding emails.

Edge Case 3: DNS Propagation Delays

The Failure Condition: After updating DNS records, Genesys still reports verification failures.

The Root Cause: DNS changes can take up to 48 hours to propagate globally, though typically it takes 1-4 hours. Genesys may cache DNS records or check from a specific geographic location that has not yet received the update.

The Solution:

  1. Wait for the TTL (Time To Live) of the old records to expire.
  2. Use dig with the +trace option to verify propagation from multiple locations.
  3. In Genesys, click Verify again. If it fails, check the error message. If it says “Record not found,” ensure the record is published correctly. If it says “Invalid value,” check for syntax errors (e.g., missing semicolons in DKIM).

Official References