SPF, DKIM, and DMARC information is published in DNS as TXT records.
An SPF record must be defined for each position where email will be seen as originating from, as shown in an e-mail message's MAIL FROM envelope header (also known as the bounce address or return path of the message - RFC 5321).
So since messages I send from here have a MAIL FROM address of email@example.com appearing in the message, I need to have an SPF record defined for agari.com.
Likewise if I had email originating MAIL FROM address of firstname.lastname@example.org for some reason, then I would need to have SPF defined for feedback.agari.com!
SPF record definitions are not inherited by lower order hostnames.
Please consult a resource such as www.openspf.org for specifics on SPF.
In the cases of DKIM and DMARC, the TXT record entries are never the same as the hostname/domain specified in the relevant A record, because there are specifications actually determining the location of the data. With DMARC the record is published at _dmarc.<From domain>.
For instance with my example of email@example.com, I would need to have my DMARC record defined in DNS as a TXT record at this position: _dmarc.agari.com.
Because DMARC entries are inherited by lower order hostnames, my further example in firstname.lastname@example.org would not need to have its own specific DMARC entry unless variances in behaviour are desired. In that case you might want to define DMARC at _dmarc.feedback.agari.com.
Please consult www.dmarc.org for specifics on DMARC.
DKIM information exists at a location similar to DMARC, but with variations depending on the key used to sign messages being sent from the origination.
For example, Agari's DKIM information would *always* be defined in a DNS TXT record such as KEY._domainkey.agari.com, where KEY can vary based on choices made by the sending service, and even the domain can vary based on information specified in the signed message headers. (KEY._domainkey.<d=domain>)
In the specific case of Agari, the record is s1024._domainkey.agari.com, but without having seen a message with the relevant clues you would have no way of knowing that. 's1024' could just as easily be 'myfavoritetruck'. In addition, other DKIM entries may be defined at differing positions, to fulfill varied signing requirements.
Please consult resources such as www.dkim.org for specifics on DKIM.
A further note on DMARC tying SPF and DKIM together: DMARC requires that the MAIL FROM domain used for SPF and the signing domain (d=) used for DKIM align with the From header domain (RFC 5322, the From header which users actually see in their email clients). So if the domain owner intends to apply DMARC policies to their messages they must ensure that these two domains used in their messages are an exact match or have sub-domain relationship to the From header domain. This is called having proper alignment.
Here are some examples of looking up these record types. If you do not have access to nice command-line tools such as 'dig' or 'nslookup', try website DNS utilities.
dig +short txt agari.com
"v=spf1 ip4:18.104.22.168 ip6:2001:a60:901e::22 ip4:22.214.171.124 ip4:126.96.36.199 ip4:188.8.131.52 ip4:184.108.40.206 ip4:220.127.116.11 ip4:18.104.22.168 include:_spf.google.com include:support.zendesk.com -all"
dig +short txt _dmarc.agari.com
dig +short txt s1024._domainkey.agari.com
"v=DKIM1\; k=rsa\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDQwPqBxkIOc1YVnJv3Occfbd3S68p8E5BafsirMBaSPxqIgnzaxNSyPp8INEPL61cIRKo3u195Px5XHNwjEfq76BvDu7eUYXxY8zKcAS74heKAeyfpVaMFWHUzCoujPNzzorCIRtP5CuY+ILw+Vj1SKN6xlBWhouCSHWhOr/vcYQIDAQAB"