SPF & DMARC alignment

Nothing changes for the recipient

The message a recipient receives is delivered by your own platform — Microsoft's or Google's servers, from their IP ranges. Their SPF check evaluates those addresses against your record, which already lists them (include:spf.protection.outlook.com or include:_spf.google.com). SPF passes exactly as it did before RubySig.

DKIM is signed by RubySig as your domain (DKIM), so From: and the signing domain align, and DMARC passes on both SPF and DKIM.

The return leg

There is one hop the recipient never sees: RubySig handing the stamped message back to your platform. Your platform runs its own authentication on that hop, and it sees the relay's address as the sender.

Both platforms accept the message regardless — that is what the inbound connector (Microsoft) and the SMTP relay allow-list (Google) are for. But adding the relay to your SPF record lets that hop pass SPF too, which keeps Microsoft's composite authentication clean and avoids the returned copy ever being scored as suspicious by your own tenant.

Add to your existing SPF record, before the final -all or ~all:

ip4:167.233.237.1 ip6:2a01:4f8:c015:909d::1

For example, a Microsoft 365 domain:

v=spf1 include:spf.protection.outlook.com ip4:167.233.237.1 ip6:2a01:4f8:c015:909d::1 -all

Note: A domain may have only one SPF record. Edit the existing one; do not add a second TXT record starting with v=spf1. Two SPF records is a permanent fail at every receiver.

DMARC policy

If you publish DMARC (and you should), no change is needed. RubySig's DKIM signature aligns with your From: domain, so p=quarantine and p=reject policies are satisfied. If you are moving from p=none to an enforcing policy, do it after the DKIM record is showing Published in the portal and a test message shows dkim=pass for your domain — see Verifying your setup.