Let's break this down, since you have a few different components working for you here.
If I am reading this right, all the emails have a from email address of @example.com (regardless of what server is sending them) so my items below are tuned for sending from @example.com
Also, your real problem looks to be with DKIM (since you are getting the email, just not seeing it as signed). I'm including other things to clean up that'll help you in the long run.
DKIM
Since you note that you sometimes get messages in Gmail that say they are DKIM signed, I am going to assume you have the selector portion correct and that the outbound mail server is properly adding DKIM signatures to your outbound messages. The problem sounds like you don't have your outbound mail server for the PHP web page setup to do DKIM signing. The easiest way would be to have your web server send the email out through the same mail server you mailboxes use; they've already proven they properly sign messages and that would consolidate your mailflow into a single route.
This is important, because DKIM is the only part of this setup that requires you to modify the mail flow. SPF and DMARC are DNS-based instructions to receiving servers that tell them how to check for and handle fake mail claiming to be from your domain. DKIM actually modifies the mail from your servers so that there is proof it is 100% from you. If there are not DKIM signature headers in the email you send, then you aren't properly signing outbound emails and DMARC will fail later on.
Your current DKIM records in DNS are a little much, in fact, it looks like you are including some elements that are meant for the mail headers and not for DNS; and you have a bad value for testing flag with "t=s". For the purpose of most anything you need DKIM for, the DNS record is super-simple; as in, just 2 or 3 elements, the DKIM version and the public key (and, maybe, the testing flag). Also, the testing flag is set with "t=y" otherwise you'll encounter issues.
Since we are still testing this, I'll include the test flag, but make sure to remove that once everything is working for you.
For testing
com.example._domainkey.selector TXT "v=DKIM1; t=y; p=[public DKIM sign key]"
For production (remove the testing flag)
com.example._domainkey.selector TXT "v=DKIM1; p=[public DKIM sign key]"
Everything else is unnecessary, so lets clean that up a bit. All the DNS entry is doing is giving the whole world a copy of your private key so they can check the signature for themselves. (and listing that this domain is still testing DKIM, so don't reject a message just because it fails the DKIM check)
DKIM records are about the domain in the From-line of an email. So if your mail is coming FROM @example.com then that is the DKIM that will be used.
SPF
Sender Policy Framework is about identifying what servers are allowed to send emails that claim to originate from your domain. You have several elements listed in your SPF record that wouldn't normally be used in a strong setup. There is also a general syntax error, you're using too many "+" symbols. You don't need a "+" before each of the elements. In fact, given your records, you don't need a "+" anywhere in your SPF records, get rid of those.
- mx : This signifies that any of the servers that can receive mail for the domain (the Mail eXchangers) are also allowed to send mail outbound from your domain. This element is fairly common, especially in smaller mail systems.
- a : This one bothers me a bit. This element says that "anything with an A-record in my domain is allowed to send email from my domain." That is normally overly-permissive and can let too many things send (literally any host in your DNS). I'd consider removing this element unless you absolutely must have it.
- ip4 : This one is straight-forward. Allow this IP address to send email for this domain. If you have static IP addresses that shouldn't ever change, then this is a decent way to go. If you list the IP addresses of all the authorized sending services, then you don't need the a or mx elements as they'd be redundant.
- include : This element means that you want to use the SPF record located at the address attached to the include element. This is only used when you have a good SPF setup somewhere else and you need to add it to additional locations. Most commonly, this is seen when you use a 3rd party email provider (O365/Outlook/Hotmail, Google Apps, Yahoo for Biz, etc) and are setting up your domain to allow their servers to send on behalf of your doamin. It is also useful if you use a email marketing company to send mass-mailing on your behalf. I find it extremely unlikely that you have need for includes from 4 different mail hosts, you should probably remove most if not all of these. (if you use one of these hosts, make sure to use the EXACT include they give in their instructions).
- -all : This is an important record. It is the special "all" wildcard modified with a "-". That means that anything which doesn't match one of the previous entries should be rejected and blocked. This is a hard-fail indicator and is a good thing to use once you have everything working the way you want. *If you already use this domain for email and you're just now setting up SPF (or DMARC) then you might want to temporarily use the "~" soft-fail indicator. That will get emails delivered (though they may be marked as suspicious, or undergo additional spam detection because of the soft-fail). Once everything is setup and working like you want, go back to the "-" hard fail.*
Not knowing your domains, I can't test your a and mx records via DNS. But since you do have a good number of IPv4 items listed, I'd simplify the SPF records down to something like this.
For testing
com.example. TXT "v=spf1 ip4:[IP of server that is sending emails] ip4:[IP address of server.example2.com.mx] ~all"
For production (rejecting messages not from your servers)
com.example. TXT "v=spf1 ip4:[IP of server that is sending emails] ip4:[IP address of server.example2.com.mx] -all"
You can have multiple ip4: elements if you need additional IP addresses (more servers, or added interfaces on a server).
The important part here is that the TXT record for the SPF is created in DNS for the domain that the mail is from. And the ip4: elements of the SPF indicate the IP of the servers that will be allowed to send mail. They don't have to be servers for the same domain, but they do have to be all the IPs that are allowed to send email for that domain.
DMARC
DMARC is special in that it doesn't do any checking of the validity of an email, it simply tells other server how to handle emails if they fail SPF or DKIM checks.
It looks like your DMARC record is telling servers to never reject or quarantine messages, even the failures (the "p=none; sp=none") part of the command. That's good for testing as long as you remember to turn it up a notch when you're finished testing.
Also, the DKIM and SPF identifier alignment elements of the record default to "relaxed" (the recommended setting) so you can leave those out to simplify it a bit. Otherwise, this one looks pretty good.
For testing
com.example._dmarc TXT "v=DMARC1; p=none; sp=none; pct=100;"
For production (with hard rejects of failures"
com.example._dmarc TXT "v=DMARC1; p=reject; sp=reject; pct=100;"
