Rev.io SPF, DKIM and DMARC setup, step by step

Start in Rev.io PSA’s Outbound Mailboxes settings and use the DNS instructions issued for that mailbox’s domain. The native workflow uses SendGrid-assisted domain authentication, but you should not create an unrelated SendGrid account or paste another customer’s records. Complete DNS publication and then validate the mailbox inside Rev.io before testing actual mail. Rev.io outbound validation.

This guide covers the documented Rev.io PSA outbound mailbox workflow for system and workflow communications. It does not establish the configuration for the separate Rev.io Billing platform, legacy deployments or independently connected mail services. No customer account, DNS or delivered-message testing was performed.

Before you begin

You need authorization to administer PSA email settings, access to the logged-in user’s mailbox, and an authorized administrator of the domain’s authoritative DNS. Confirm the intended From domain and whether this change should affect ordinary system messages, workflow notifications, or both.

Record existing mailbox defaults, DNS records, applicable DMARC policy and any shared sender dependencies. The public instructions do not establish universal subscription or role entitlements. If the required controls are absent, ask Rev.io support about the actual tenant rather than granting broader permissions speculatively.

Obtain the native record set

1. Navigate to Admin > System Settings > Email > Outbound Mailboxes.
2. Choose Add Mailbox, enter the approved sender name and email address, and save using Add Mailbox.
3. Check the mailbox of the user currently logged into Rev.io, not just the newly entered From address. Rev.io documents a SendGrid validation message to that logged-in user.
4. Give the expected setup instructions to your authorized DNS administrator through an approved channel. Confirm the request is the one you initiated; a display name alone is not proof of a safe link.
5. Publish the tenant-issued records after the checks below. Complete the instruction page’s I’m Done step.
6. Return to the outbound mailbox, edit it and select Validate. The documented success state includes a dated green validation message; failures should be escalated through Help & Support.

Rev.io says another outbound address on the same already-validated domain does not need repeat validation. Still verify its actual sending path and selected defaults. Official validation workflow.

Read the records by purpose, not by resemblance

The official illustration contains a tenant-specific envelope/bounce alias, two _domainkey CNAME aliases, link-related aliases and a DMARC example. It is a demonstration, not a reusable record set. Copy the exact types, complete owners and targets from the instructions issued for your own domain. Do not copy the pictured selectors, numbers or customer domain.

• DKIM aliases let receivers obtain public signing keys. DNS publication is not proof that the intended signature is present or passing on actual messages.
• Envelope/bounce authentication is separate from visible From. Do not assume an SPF record belongs at the root of your business domain merely because that domain appears in the sender address.
• Link-related records do not by themselves prove SPF, DKIM or DMARC alignment. Ask support to resolve an unexpected record or collision before proceeding.
• DMARC policy belongs to the domain owner. A suggested monitoring value is not permission to replace existing protection.

An issued CNAME owner cannot also hold a conflicting TXT, A, AAAA, MX or second CNAME. If a proposed alias conflicts with another sender’s selector, an existing delegation or a shared record, stop and request a supported non-conflicting configuration. Never remove a nameserver delegation just to make the form accept a value.

Put each record in the correct DNS zone

Illustrative owner names below are placeholders, not Rev.io records:

• Full owner KEY._domainkey.mail.example.com, managed in zone example.com: a relative-name editor usually needs KEY._domainkey.mail.
• The same owner in a separately delegated mail.example.com zone: usually KEY._domainkey.
• The same owner in a delegated _domainkey.mail.example.com zone: usually KEY.

Some DNS interfaces accept full names; others append the zone automatically. Inspect the final stored name to prevent duplicated suffixes. Leave unrelated NS, MX, DNSSEC and existing sender records unchanged.

For Cloudflare-hosted CNAME verification records, use DNS-only rather than HTTP proxying. For each issued alias requiring a literal CNAME answer, disable its applicable per-record Flatten option where available, and ensure applicable zone-wide flattening does not hide that answer. Preserve unrelated global settings and records. Mandatory apex or same-zone flattening can prevent this end state; stop and ask the DNS host and Rev.io for a supported arrangement rather than forcing a conflicting configuration. Cloudflare flattening controls and exceptions.

SPF and DMARC safeguards

SPF evaluates the actual SMTP MAIL FROM domain, not automatically the visible From address. If the supplied setup delegates an envelope owner by CNAME, do not add a conflicting SPF TXT at that owner. If support instead supplies a TXT-based route, preserve existing legitimate authorizations and publish only one SPF policy at the evaluated owner. SPF’s limit is ten evaluated DNS-dependent terms, including nested mechanisms, not merely ten top-level includes; redirect is ignored when all is present. SPF evaluation and lookup limits.

Preserve the existing direct or inherited DMARC policy and approved reporting destinations. The provider screenshot’s monitoring example is not an instruction to downgrade an established policy. Only where no applicable policy exists, and the domain owner approves a monitoring plan, may a first record use:

Type: TXT
Full owner: _dmarc.YOUR-FROM-DOMAIN
Value: v=DMARC1; p=none;

Replace the placeholder with the actual From domain. In an example.com zone, a policy for mail.example.com normally uses relative owner _dmarc.mail; in a separately delegated mail.example.com zone, it uses _dmarc. Do not create duplicate policies. This example has no reporting address, so it does not arrange aggregate-report delivery.

If reports will go to a destination in a different Organizational Domain, receiving systems must check the external reporting authorization; destinations within the same Organizational Domain are excepted. Obtain domain-owner approval for sharing report data as well: DNS authorization does not replace that privacy decision. DMARC aggregate-report authorization.

Under relaxed DMARC alignment, related subdomains within the same Organizational Domain can align; under strict alignment the domain must match exactly. For example, d=mail.example.com can align with From example.com in relaxed mode, not strict mode. A child envelope domain has the same strict-SPF limitation. Do not promise strict alignment until the actual route’s identities are verified. DMARC alignment.

Select defaults deliberately

Rev.io separates the normal outbound default from the Workflow Default. A successfully validated address is not proof every notification now uses it. Select the appropriate default only when that routing change is approved, then test each relevant message class. Do not change support inboxes, inbound reply handling, spam filtering or quarantine settings as part of outbound authentication. Outbound mailbox fields and defaults.

Verify DNS, validation and actual delivery separately

Read-only DNS queries can check what is publicly published. Substitute actual issued owners before running these examples:

dig CNAME ISSUED-DKIM-OWNER
dig CNAME ISSUED-ENVELOPE-OWNER
dig TXT _dmarc.YOUR-FROM-DOMAIN

Compare responses with the issued types and complete targets. No responses are fabricated here. Missing results may mean the wrong DNS zone, propagation delay or a naming error; do not keep creating duplicate records. Retry native validation after correcting the specific issue and allowing caches to update.

Next use a controlled, authorized message through the intended PSA route, with no sensitive content. Do not issue a purchase order, invoice or external customer notification merely for testing. If no safe test path exists, coordinate inspection of the next legitimate message.

Inspect the original message at trusted receiving infrastructure:

• The visible From must remain the intended business address. A rewritten vendor-domain From is not successful brand authentication.
• The intended Rev.io-route DKIM signature must pass and align with that From under the current policy, and the trusted receiver must report dmarc=pass. A DMARC pass via SPF alone does not prove DKIM works.
• Record the actual envelope domain and SPF result separately. Investigate SPF fail, temporary DNS errors and permanent policy errors even if aligned DKIM allows DMARC to pass.
• Repeat for both ordinary system and workflow messages where both are in scope.

Use Authentication-Results from the known receiving system’s processing boundary, with its documented handling of externally supplied Authentication-Results, not arbitrary headers inserted by a sender. Ask the receiving-mail administrator which results are attributable to that trusted processing step if this is unclear. Header position or a matching server identifier string alone is insufficient. Authentication-Results trust boundary. For interpretation, see raw DKIM versus aligned policy results, checked against its retained body rather than a fresh live-page test.

Troubleshooting and rollback

No setup email: check the initiating user’s mailbox and confirm the initiated request with support. Do not repeatedly create addresses or forward the setup message to unapproved recipients.

Validation fails: compare complete owners, types and targets; inspect DNS authority, collisions and conditional proxy/flattening behavior. Escalate the exact native error through Rev.io Help & Support without sending credentials or private keys.

Validated but wrong sender: check the normal and workflow defaults separately, then inspect the actual message path. Native validation alone is not a delivered-message audit.

A change affects another service: stop further rollout. Restore only the records or defaults changed in this approved change, after checking dependencies. Do not delete shared aliases, unrelated DKIM selectors or an existing DMARC policy. Preserve a redacted before/after record for the DNS owner and support.